8.2 审计与合规 审计的价值 日志平台本身也需要被审计，确保配置变更、用户操作可追溯。 常见审计内容 用户登录与权限变更 告警规则与通知变更 Stream/Pipeline 修改 索引与保留策略调整 合规建议 重要操作启用双人审核 关键配置定期备份 日志保留符合合规要求（如 180 天） 小结 审计能力是安全治理的重要部分。下一章进入备份与恢复。 下一节：8.3 备份与恢复 返回目录 | 返回首页

8.1 用户与权限 权限模型 Graylog 使用 用户-角色-权限 模型，权限粒度覆盖索引、搜索、流、仪表盘与告警。 常见角色划分 Admin：全局管理 Operator：运维管理 Viewer：只读访问 配置建议 最小权限原则 业务团队只访问必要索引 安全团队拥有审计与告警权限 小结 权限控制是治理基础。下一章介绍审计与合规。 下一节：8.2 审计与合规 返回目录 | 返回首页

7.3 告警降噪 为什么要降噪 无效告警过多会导致告警疲劳，降低响应效率。 常用策略 分级告警：按严重程度分级 静默窗口：对重复告警设置冷却时间 去重规则：相同条件短时间内只触发一次 阈值调优：避免过低阈值 实践建议 先收集数据，再调整阈值 结合业务高峰时段 输出可操作建议 小结 降噪是告警体系成熟度的关键指标。下一章进入用户与权限。 下一节：8.1 用户与权限 返回目录 | 返回首页

7.2 通知渠道 常见通知方式 Email Slack/Teams Webhook 企业微信/钉钉（通过 Webhook） 配置步骤 System → Alerts → Notifications 新建 Notification 选择类型并填入目标地址 绑定到 Event Rule 建议 统一告警模板格式 提供关键信息：服务、时间、影响、建议动作 按严重级别分级通知 小结 通知渠道决定告警触达效率。下一章介绍告警降噪。 下一节：7.3 告警降噪 返回目录 | 返回首页

7.1 事件规则 事件规则是什么 事件规则用于定义“什么时候触发告警”，通过条件判断和聚合统计生成事件（Event）。 常见规则类型 Aggregation：聚合统计（最常用） Correlation：关联规则（高级） Filter & Conditions：过滤与条件 示例：5 分钟内 5 次 500 错误 query: http_status:500 within: 5 minutes threshold: 5 建议 先定义明确的业务指标 从简单阈值开始 设置合适的时间窗口 小结 事件规则是告警体系的基础。下一章介绍通知渠道。 下一节：7.2 通知渠道 返回目录 | 返回首页

6.3 共享与权限 为什么需要权限控制 团队协作中，需要对搜索、仪表盘、视图进行权限隔离，保证数据安全与角色分工。 共享方式 私人：仅自己可见 共享：指定用户或角色 只读：允许查看但不能修改 常见实践 运维只读、开发只读 安全团队拥有告警与审计权限 业务团队仅查看特定流量视图 小结 权限控制是治理体系的一部分。下一章进入事件规则。 下一节：7.1 事件规则 返回目录 | 返回首页

6.2 Views 与聚合 Views 的作用 Views 是更灵活的可视化与搜索集合，可以组合搜索、聚合与图表，适合构建复杂分析页面。 常见聚合方式 计数（Count） 平均值（Avg） 最大/最小（Max/Min） 分组（Group by 字段） 示例场景 按服务聚合错误数 按状态码统计比例 按主机展示请求量趋势 建议 使用结构化字段进行分组 保持查询范围合理 复用 Saved Search 作为数据源 小结 Views 适合复杂分析与看板。下一章介绍共享与权限。 下一节：6.3 共享与权限 返回目录 | 返回首页

6.1 Dashboards 入门 Dashboard 是什么 Dashboard 用于将多个图表组件组合在一起，形成统一视图。适合运维、业务与安全场景的指标展示。 常见组件 计数指标：日志数量、错误数 时间序列：请求量趋势 TopN 列表：错误 Top 服务/主机 饼图/柱状图：比例分布 创建步骤 新建 Dashboard 选择数据源（Saved Search） 添加组件并布局 保存与共享 实战建议 先整理好字段规范 用 Saved Search 复用查询 关注关键业务指标 小结 Dashboard 是可视化的入口。下一章介绍 Views 与聚合。 下一节：6.2 Views 与聚合 返回目录 | 返回首页