Hadoop 集群的稳定运行离不开完善的监控体系，搭建涵盖集群负载监控与日志收集的监控系统，可实时掌握集群运行状态，及时发现潜在问题。在集群负载监控方面，Ganglia 是常用的分布式监控工具，能够收集并展示集群中各节点的 CPU 使用率、内存占用量、磁盘 IO 速率、网络流量等关键指标，帮助运维人员实时了解节点负载情况。Ganglia 的架构包含 gmond（Ganglia Monitoring Daemon）、gmetad（Ganglia Meta Daemon）和 Web 前端三部分：gmond 运行在每个被监控节点上，定期采集节点的系统资源指标，并通过多播或单播方式将指标数据发送给其他节点或 gmetad；gmetad 运行在监控主节点上，负责收集多个 gmond 发送的指标数据，存储到 RRDtool（Round Robin Database tool）数据库中，并支持聚合多个集群的监控数据；Web 前端基于 PHP 开发，通过读取 RRDtool 数据库中的数据，以图表形式直观展示集群负载趋势（如 CPU 使用率变化曲线、内存占用饼图等），运维人员可通过浏览器访问 Web 界面，实时查看集群状态，当某个节点的 CPU 使用率持续过高或内存不足时，可及时介入处理，避免影响集群服务。
在日志收集方面，ELK（Elasticsearch + Logstash + Kibana）栈是 Hadoop 集群日志管理的常用方案，能够实现日志的收集、存储、检索与可视化分析。Logstash 作为日志收集工具，可部署在 Hadoop 集群的 NameNode、DataNode、ResourceManager 等节点上，通过配置输入（Input）、过滤（Filter）、输出（Output）插件，收集各节点的 Hadoop 日志（如 NameNode 的 hadoop-hdfs-namenode-xxx.log、DataNode 的 hadoop-hdfs-datanode-xxx.log）。例如，在 Logstash 的配置文件中，通过file输入插件指定日志文件路径，通过grok过滤插件解析日志格式（如提取日志时间、日志级别、日志内容等字段），通过elasticsearch输出插件将解析后的日志数据发送到 Elasticsearch 中存储。以下是一个 Logstash 收集 Hadoop DataNode 日志的配置示例
input {
file {
path => "/var/log/hadoop/hdfs/hadoop-hdfs-datanode-*.log"
start_position => "beginning"
sincedb_path => "/dev/null"
type => "datanode-log"
}
}
filter {
grok {
match => { "message" => "%{TIMESTAMP_ISO8601:log_time} %{LOGLEVEL:log_level} [%{DATA:thread}] %{DATA:class} - %{GREEDYDATA:log_content}" }
}
date {
match => [ "log_time", "yyyy-MM-dd HH:mm:ss,SSS" ]
target => "@timestamp"
}
}
output {
elasticsearch {
hosts => ["192.168.1.100:9200"]
index => "hadoop-datanode-log-%{+YYYY.MM.dd}"
}
stdout { codec => rubydebug }
}
Elasticsearch 作为分布式搜索引擎，负责存储 Logstash 发送的日志数据，并提供高效的全文检索能力，运维人员可通过 Elasticsearch 的查询 API，根据日志级别、时间范围、关键字等条件快速检索日志（如查询 “ERROR” 级别的 DataNode 日志）。Kibana 作为可视化工具，基于 Elasticsearch 的数据，提供日志仪表盘、趋势图表等功能，运维人员可通过 Kibana 查看日志分布情况、错误日志统计等，快速定位日志中的异常信息，提高故障排查效率。
在 Hadoop 集群运维中，常见故障的及时处理是保障集群稳定的关键。当 DataNode 磁盘写满时，会导致 DataNode 无法存储新的数据块，影响 HDFS 的正常读写，此时需采取应急方案：首先通过hdfs dfsadmin -report命令查看各 DataNode 的磁盘使用情况，定位磁盘写满的 DataNode 节点；然后登录该节点，检查 HDFS 数据目录（如/data/hadoop/hdfs/data）下的文件占用情况，若存在非 HDFS 的冗余文件（如日志备份、临时文件），可删除冗余文件释放磁盘空间；若磁盘空间仍不足，可添加新的磁盘到 DataNode 节点，修改 HDFS 配置文件hdfs-site.xml中的dfs.datanode.data.dir参数，添加新磁盘的挂载路径，重启 DataNode 服务，使新磁盘生效；同时，可通过hdfs balancer命令将该 DataNode 上的部分数据块迁移到其他磁盘空闲的 DataNode 节点，平衡磁盘负载。
NameNode 堆内存溢出是另一常见故障，由于 NameNode 需要存储 HDFS 的元数据（如文件与数据块的映射关系），当集群中文件数量过多时，若堆内存配置不足，会导致 NameNode 内存溢出，进而影响整个 HDFS 集群的可用性。解决该问题需调优 NameNode 的堆内存参数（-Xmx）：首先分析 NameNode 的内存使用情况，通过jstat -gc <NameNode进程ID>命令查看堆内存的使用情况（如 Eden 区、Old 区的使用率），估算所需的堆内存大小（通常每百万个文件需要 1GB 左右的堆内存）；然后修改 Hadoop 的配置文件hadoop-env.sh，找到HADOOP_NAMENODE_OPTS参数，设置堆内存大小，例如export HADOOP_NAMENODE_OPTS="-Xms4g -Xmx8g -XX:+HeapDumpOnOutOfMemoryError"，其中-Xms设置初始堆内存，-Xmx设置最大堆内存，-XX:+HeapDumpOnOutOfMemoryError配置内存溢出时生成堆转储文件，便于后续分析溢出原因；最后重启 NameNode 服务，使配置生效，同时通过jmap -heap <NameNode进程ID>命令验证堆内存配置是否生效，确保 NameNode 有足够的内存存储元数据。
Hadoop 集群的安全实践同样重要，Kerberos 认证和 HDFS 权限控制是保障集群安全的关键手段。Kerberos 作为网络认证协议，可实现 Hadoop 集群中各节点与用户的身份认证，防止未授权访问。配置 Kerberos 认证的步骤如下：首先部署 Kerberos 服务器（如 MIT Kerberos），创建 Kerberos 数据库和管理员账号；然后在 Hadoop 集群的所有节点上安装 Kerberos 客户端，配置krb5.conf文件，指定 Kerberos 服务器地址和 Realm 信息；接着为 Hadoop 的各服务（如 NameNode、DataNode、ResourceManager）创建 Kerberos 主体（Principal），并生成密钥表文件（Keytab），将密钥表文件分发到对应的服务节点；修改 Hadoop 的配置文件（如core-site.xml、hdfs-site.xml），启用 Kerberos 认证，配置相关参数（如hadoop.security.authentication设置为kerberos，hadoop.security.authorization设置为true）；最后重启 Hadoop 集群服务，用户需通过kinit命令认证身份后，才能访问 HDFS 或提交任务，确保集群的访问安全。
HDFS 权限控制通过 ACL（Access Control List）实现更精细的权限管理，除了传统的所有者、所属组、其他用户的权限控制（r：读权限，w：写权限，x：执行权限），ACL 还允许为特定用户或用户组设置权限，满足复杂的权限需求。例如，某个 HDFS 目录/user/project的所有者为user1，所属组为dev，默认权限为rwxr-xr--，若需要让用户user2拥有该目录的写权限，可通过 ACL 命令设置：首先执行hdfs dfs -setfacl -m user:user2:rwx /user/project，为user2添加读、写、执行权限；然后通过hdfs dfs -getfacl /user/project命令查看 ACL 配置，验证权限是否生效。此外，还可通过hdfs dfs -setfacl -x user:user2 /user/project删除user2的 ACL 权限，或通过hdfs dfs -setfacl -b /user/project清除所有 ACL 权限，恢复默认权限控制。通过 ACL 命令集，运维人员可灵活管理 HDFS 目录和文件的权限，确保数据的安全性与访问可控性。
)