请求在Azure中构建App Insight监控Linux服务器Inotify服务的方案与步骤

我来帮你梳理下怎么用Azure Application Insights（简称App Insights）监控Linux上的Inotify服务，包括具体操作步骤和实战建议——这些都是我实际部署过的经验总结，应该能帮你少踩坑：

一、前置准备 #

先确认你手上有这些东西：

• 有效的Azure账号，并且有权限创建App Insights资源和配置Azure Monitor Agent
• 运行Inotify的Linux服务器（已经安装inotify-tools包，比如inotifywait）
• 服务器能正常连接Azure网络（如果是本地服务器，需要打通网络到Azure；Azure VM的话直接用内网就行）

二、具体操作步骤 #

1. 创建Application Insights资源 #

首先得在Azure上搭好监控的"接收端"：

• 登录Azure Portal，搜索「Application Insights」，点击「创建」
• 填写基础信息：选择订阅、资源组，给资源起个好记的名字，选就近的区域
• 资源模式选基于工作区的（这是Azure现在推荐的模式，和Log Analytics集成更灵活）
• 点击「查看+创建」，确认信息后完成部署
• 部署完成后，进入资源详情页，找到左侧菜单的「连接字符串」，复制下来——这个是后续服务器和App Insights通信的关键凭证

2. 在Linux服务器上安装Azure Monitor Agent（AMA） #

AMA是现在Azure推荐的监控代理，用来收集服务器上的日志、指标并传到Azure，代替了旧的Log Analytics Agent：

• 如果服务器没装Azure CLI，先装：

  curl -sL https://aka.ms/InstallAzureCLIDeb | sudo bash
  

• 登录Azure CLI：az login（如果是Azure VM，也可以用系统托管身份验证，更安全）
• 安装Connected Machine扩展（用来关联服务器和Azure）：

  az extension add --name connectedmachine
  

• 把服务器注册到Azure：

  az connectedmachine connect --resource-group <你的资源组名称> --name <服务器的显示名称> --location <服务器所在区域>
  

• 如果是Azure虚拟机，更简单：直接在VM的「监控」菜单里，找到「Azure Monitor Agent」，一键启用就行

3. 配置Inotify的日志输出 #

Inotify默认不会把操作记录持久化，所以我们得写个脚本把监控日志输出到文件，方便AMA收集：

• 创建监控脚本/usr/local/bin/inotify-monitor.sh：

  #!/bin/bash
  # 替换成你要监控的目标目录
  MONITOR_DIR="/path/to/your/target/directory"
  # 日志输出路径
  LOG_FILE="/var/log/inotify-monitor.log"
  
  # 确保日志文件存在并设置合适权限
  touch $LOG_FILE
  chmod 644 $LOG_FILE
  
  # 启动inotifywait，监控常见操作并输出结构化日志
  inotifywait -m -r -e create,delete,modify,move --format '%Y-%m-%d %H:%M:%S %w%f %e' $MONITOR_DIR >> $LOG_FILE
  

• 给脚本加执行权限：sudo chmod +x /usr/local/bin/inotify-monitor.sh
• 配置systemd服务让脚本开机自启：创建/etc/systemd/system/inotify-monitor.service：

  [Unit]
  Description=Inotify Directory Monitor Service
  After=network.target
  
  [Service]
  Type=simple
  ExecStart=/usr/local/bin/inotify-monitor.sh
  Restart=always
  # 建议用非root用户运行，比如创建专门的monitor用户
  User=root
  
  [Install]
  WantedBy=multi-user.target
  

• 启动并启用服务：

  sudo systemctl daemon-reload
  sudo systemctl start inotify-monitor.service
  sudo systemctl enable inotify-monitor.service
  

• 验证日志：tail -f /var/log/inotify-monitor.log，操作一下目标目录，应该能看到类似2024-05-20 14:30:00 /path/to/file.txt CREATE的日志

4. 配置App Insights收集自定义日志 #

现在要让AMA把inotify的日志传到App Insights：

• 登录Azure Portal，找到你的App Insights对应的Log Analytics工作区（基于工作区的App Insights会关联一个Log Analytics工作区）
• 进入工作区的「表」菜单，点击「创建」→「自定义日志（AMA）」
• 选择你的Linux服务器作为数据源
• 输入日志文件路径：/var/log/inotify-monitor.log
• 给自定义表起个名字，比如Inotify_CL（Azure自定义表默认后缀是_CL）
• 配置日志解析规则：因为我们的日志格式是「时间戳 文件路径 操作」，可以用Kusto查询解析：

  Inotify_CL
  | parse RawData with Timestamp:datetime " " FilePath:string " " Operation:string
  | project Timestamp, FilePath, Operation, Computer
  

• 保存配置，等待10-15分钟，日志就会开始流入App Insights了

5. 搭建监控仪表盘和告警 #

日志进来后，就可以做可视化和告警了：

• 自定义仪表盘：进入App Insights的「仪表盘」，点击「添加图表」，用Kusto查询生成图表，比如展示每小时的操作类型分布：

  Inotify_CL
  | parse RawData with Timestamp:datetime " " FilePath:string " " Operation:string
  | summarize OperationCount=count() by bin(Timestamp, 1h), Operation
  | render columnchart
  

• 告警规则：进入App Insights的「警报」→「创建警报规则」，选择「自定义日志」作为信号源，设置条件（比如5分钟内出现超过100次DELETE操作就触发告警），然后配置通知方式（邮件、Microsoft Teams、Webhook等）

三、实战实施建议 #

这些是我踩过坑后总结的实用技巧：

• 日志结构化优先：建议把inotify的日志改成JSON格式，比如修改脚本的--format参数为：

  --format '{"timestamp":"%Y-%m-%d %H:%M:%S","file":"%w%f","event":"%e"}'
  

  这样后续用Kusto解析会更灵活，也方便扩展更多字段
• 最小权限原则：不要用root用户运行inotify服务，创建一个专门的用户（比如inotify-monitor），只给目标目录的读写权限，降低安全风险
• 减少不必要的日志：如果监控的目录很大，用--exclude参数排除临时文件目录、缓存目录等，比如：

  inotifywait -m -r -e create,delete,modify,move --exclude '/path/to/temp' --format ...
  

  这样能减少日志量，降低Azure的存储成本
• 监控服务本身状态：除了inotify的操作日志，还要监控inotify服务是否存活，可以用AMA的自定义指标功能，或者写个脚本定期检查进程状态，把状态传到App Insights
• 合理设置日志保留期：在Log Analytics工作区的「数据保留」里调整保留时间，默认是30天，根据业务需求设置，避免不必要的存储开销
• 故障排查技巧：如果日志没流入App Insights，先检查AMA服务状态：sudo systemctl status azuremonitoragent，然后看AMA的日志：/var/log/azure/Microsoft.Azure.Monitor.AzureMonitorAgent/，再检查自定义日志的文件路径是否配置正确

内容的提问来源于stack exchange，提问作者Anirudh B