1. 项目概述为什么我们需要一个开源的APM在分布式系统和微服务架构大行其道的今天应用的性能问题排查变得越来越像“大海捞针”。一个用户请求从前端到后端可能穿越了十几个甚至几十个服务任何一个环节的延迟或异常都会导致最终用户体验的崩塌。这时候一个靠谱的APM应用性能管理工具就成了运维和开发团队的“眼睛”和“耳朵”。它能告诉你用户在哪里卡住了哪个服务拖了后腿数据库查询是不是太慢了内存是不是泄漏了市面上有New Relic、AppDynamics、Dynatrace这些商业巨鳄功能强大但价格不菲对于初创公司、预算有限的团队或者有高度定制化需求的场景来说门槛不低。Scouter的出现正好填补了这个空白。它是一个纯开源、功能全面的APM解决方案从Java应用到主机监控再到通过插件生态集成各种第三方组件它提供了一套从数据采集、存储到可视化分析的完整工具链。我最早接触Scouter是在一个Tomcat应用频繁出现Full GC告警的项目里当时苦于没有现成的工具能深入JVM内部看个究竟直到发现了它才算是真正把性能问题的根因给揪了出来。简单来说Scouter能帮你监控三样东西用户活跃用户、访问量、服务TPS、响应时间、方法调用栈、SQL语句和资源CPU、内存、网络、连接池。它的架构非常清晰分为Agent采集数据、Server收集和存储数据和Client展示和分析数据三部分。最让我欣赏的是它的设计理念轻量、高效、可扩展。Agent对应用性能的影响即性能开销通常可以控制在3%以内这对于生产环境监控来说是完全可以接受的。2. 核心架构与组件深度解析Scouter的架构设计遵循了经典的监控系统范式但它在实现细节上做了很多优化使其特别适合Java生态和复杂的分布式环境。理解它的各个组件是如何协同工作的是后续有效部署和使用的关键。2.1 Agent部署在监控目标上的“侦察兵”Agent是数据的源头负责采集各类性能指标。Scouter提供了多种Agent覆盖了不同的监控场景。Java Agent (JVM Agent)这是Scouter的“王牌”。它通过Java Agent技术即-javaagent命令行参数在JVM启动时加载利用字节码增强Byte Code Instrumentation, BCI/ASM技术无侵入或低侵入地拦截关键方法调用。你不需要修改你的业务代码只需要在启动命令里加上它它就能自动帮你收集JVM指标堆内存各分区使用情况、非堆内存、GC次数与耗时、线程状态、类加载信息。Web请求对于Tomcat、Jetty、Resin等Servlet容器它能自动捕获每个HTTP/S请求记录其URL、响应时间、状态码并生成唯一的XLog事务日志。这是进行链路追踪和慢查询分析的基础。方法级剖析当某个服务响应慢时你可以“下钻”到这次请求看到完整的调用栈每个方法的耗时一目了然。这对于定位性能瓶颈比如是某个算法效率低还是外部调用慢至关重要。SQL剖析它能捕获应用执行的SQL语句及其执行时间、返回行数甚至绑定参数需配置。对于数据库性能调优这个功能是神器。外部调用剖析记录HTTP客户端、Redis、MongoDB等外部服务的调用耗时。实操心得Java Agent的配置项非常丰富。在生产环境我通常会关闭一些高频但非核心的指标采集比如每一条SQL的详细参数以进一步降低开销。重点开启服务调用拓扑、慢SQL和慢服务追踪这些信息对于稳定性保障已经足够。Host Agent (OS Agent)这个Agent通常以独立进程的形式运行在服务器上负责采集操作系统层面的指标CPU使用率用户态、系统态、空闲、等待。内存使用情况物理内存、交换分区。磁盘I/O读写速率、IO等待。网络流量各网卡的进出带宽、TCP连接数。进程资源占用可以关联到特定的Java进程实现JVM与主机资源的联动查看。Telegraf支持自2.0.0起这是一个非常聪明的设计。Scouter Server集成了一个Telegraf接收器。Telegraf是InfluxData旗下的开源指标收集代理拥有极其丰富的插件生态。这意味着你可以利用Telegraf的插件去采集Nginx、Apache、MySQL、Redis、Kafka、Elasticsearch、Kubernetes等几乎任何中间件或基础设施的指标然后让Telegraf将数据推送到Scouter Server。这样Scouter就极大地扩展了其监控边界而不需要为每个组件都开发独立的Agent。Zipkin集成自2.5.0起对于非Java语言如Go, Python, Node.js, C#开发的服务Scouter通过zipkin-scouter-storage组件提供了完美的解决方案。你的其他语言服务可以使用Zipkin客户端进行埋点将链路数据存储到Scouter中。在Scouter Client的XLog散点图上你就能看到跨语言的完整调用链路实现了真正的全链路追踪。2.2 Server (Collector)数据的“中枢神经”Server是Scouter的大脑它负责接收与聚合接收来自所有AgentScouter Agent、Telegraf的实时数据流。存储将性能指标Counter和时间序列数据存储在内置的H2数据库或配置的其他存储中。将详细的XLog事务日志和Profile方法剖析数据存储在磁盘文件中。告警计算根据预定义的规则实时计算指标是否触发告警。数据服务向Scouter Client提供实时和历史数据查询接口。Server采用单进程设计资源消耗很低。它的配置核心在于定义对象类型Object Type。每个被监控的实体如一个Tomcat实例、一台主机、一个MySQL实例在Scouter中都是一个“对象”属于某个“类型”。这方便了在客户端进行分组管理和视图展示。2.3 Client (Viewer)性能数据的“驾驶舱”Scouter Client是一个基于Eclipse RCP开发的桌面客户端目前暂不支持macOS Big Sur及更高版本。虽然现在Web UI是主流但这个桌面客户端的强大和高效可能会改变你的看法。它提供了多种视角来审视你的系统实时仪表盘全局视角展示所有被监控对象的健康状态、TPS、活跃用户、响应时间等关键摘要。对象列表以列表形式展示所有对象可以快速查看每个对象的实时指标。XLog视图散点图这是我最常用的功能。它将一段时间内的所有事务请求以散点形式呈现X轴是时间Y轴是响应时间。一眼就能看出响应时间的分布、是否有慢请求聚集、错误请求红色点的发生情况。点击任何一个点可以下钻查看该次请求的完整Profile。拓扑图自动或手动绘制服务之间的调用关系图并显示调用频次和平均耗时对于理解复杂的微服务架构依赖非常直观。计数器视图以图表形式展示任何指标的历史趋势如CPU、内存、堆使用率、数据库连接数等。2.4 扩展生态插件与第三方UIScouter的活力很大程度上来自于其活跃的插件生态。Server插件告警插件这是刚需。官方和社区提供了将告警发送到Email、Slack、Telegram、钉钉、Microsoft Teams等各类协作工具的插件。你可以定义灵活的告警规则比如“当某服务错误率超过5%持续1分钟”时触发。存储插件例如scouter-plugin-server-influxdb插件可以将Scouter采集的指标数据同时转发到InfluxDB时序数据库中这样你就可以用更强大的Grafana来制作自定义监控大盘实现Scouter与现有监控栈的融合。第三方UI - Scouter Paper对于偏爱Web界面的用户社区贡献了Scouter Paper这个现代化的Web UI。它提供了与桌面客户端类似的核心功能并且部署方便可以通过Docker快速启动。这为团队协作和移动端查看提供了更好的选择。3. 从零开始生产环境部署与配置实战理论说得再多不如动手搭一遍。下面我将以一个典型的生产环境场景为例带你一步步部署和配置Scouter监控一个包含Tomcat应用和MySQL数据库的Linux服务器。3.1 环境准备与规划假设我们有一台应用服务器IP: 192.168.1.100上面运行着Tomcat和一个Java Web应用。同时我们有一台独立的监控服务器IP: 192.168.1.200用于部署Scouter Server和Client。下载组件从Scouter的GitHub Release页面下载最新版本的以下包scouter-server-{version}.tar.gzscouter-client-{version}.{os}.zip(根据你的客户端操作系统选择如win32.win32.x86_64for Windows)scouter.agent.java-{version}.jarscouter.agent.host-{version}.tar.gz网络规划确保监控服务器200的TCP 6100端口Scouter Server默认端口对所有Agent服务器开放。Agent需要向这个端口发送数据。3.2 Scouter Server部署与配置在监控服务器192.168.1.200上操作# 1. 解压并移动到合适目录 tar -xzf scouter-server-*.tar.gz mv scouter-server /usr/local/ # 2. 进入目录 cd /usr/local/scouter-server # 3. 主要配置文件是 conf/scouter.conf vi conf/scouter.conf关键的配置项如下你需要根据实际情况调整# 网络绑定配置 net_collector_ip0.0.0.0 # 监听所有IP net_collector_tcp_port6100 # 默认TCP端口 net_collector_udp_port6100 # 默认UDP端口用于部分计数器 # 存储配置 db_dir./database # 指标数据存储目录 log_dir./logs # 日志目录 # 对象类型定义非常重要 obj_type_ext_1host # 定义主机类型 obj_type_ext_2tomcat # 定义Tomcat类型 obj_type_ext_3mysql # 定义MySQL类型通过Telegraf # 告警配置示例可选先配置基础功能 # 可以配置CPU、内存、响应时间等阈值规则注意obj_type_ext_*是定义自定义对象类型的地方。Agent在连接时会声明自己的类型Server根据这个类型来对对象进行分类展示。合理的命名能让客户端视图更清晰。启动Server# 使用内置脚本启动 ./startup.sh # 或者直接使用java命令便于查看日志 java -Xmx512m -classpath ./scouter-server-boot.jar scouter.boot.Boot ./lib检查日志logs/scouter.log看到类似Server started...的日志即表示启动成功。3.3 Java Agent部署与配置在应用服务器192.168.1.100上为你的Tomcat应用安装Java Agent。放置Agent JAR将scouter.agent.java-{version}.jar上传到服务器的一个固定目录例如/opt/scouter/agent.java/。配置Tomcat启动参数编辑Tomcat的启动脚本通常是$CATALINA_HOME/bin/catalina.shLinux或catalina.batWindows。 在JAVA_OPTS或CATALINA_OPTS变量中添加以下参数# 在catalina.sh中找到设置JAVA_OPTS的地方添加 export JAVA_OPTS$JAVA_OPTS -javaagent:/opt/scouter/agent.java/scouter.agent.jar export JAVA_OPTS$JAVA_OPTS -Dscouter.config/opt/scouter/agent.java/conf/scouter.conf重要提示-javaagent参数必须在所有-jar参数之前。-Dscouter.config用于指定Agent的配置文件。配置Java Agent在/opt/scouter/agent.java/conf/目录下创建或编辑scouter.conf。# 必填Scouter Server的地址和端口 net_collector_ip192.168.1.200 net_collector_tcp_port6100 net_collector_udp_port6100 # 必填本对象的名称和类型用于在Server端标识 obj_nameprod-tomcat-01 # 自定义一个唯一、易识别的名字 obj_typetomcat # 必须与Server端定义的某个obj_type_ext匹配 # 可选但重要开启详细剖析的阈值单位毫秒 profile_http_querystring_enabledtrue # 记录HTTP查询参数注意隐私 profile_fullstack_sql_enabledtrue # 记录完整SQL调用栈 profile_fullstack_service_enabledtrue # 记录完整服务调用栈 trace_interservice_enabledtrue # 开启服务间调用追踪用于拓扑图 # 设置慢服务阈值超过此时间的请求会触发详细方法剖析 profile_service_ms_threshold3000 # 3秒 # 设置慢SQL阈值 profile_sql_ms_threshold1000 # 1秒obj_name建议采用{环境}-{角色}-{序号}的命名规范如prod-payment-service-01这样在客户端一眼就能定位。重启Tomcat应用配置后重启你的Tomcat服务。$CATALINA_HOME/bin/shutdown.sh $CATALINA_HOME/bin/startup.sh验证查看Tomcat的启动日志catalina.out搜索“Scouter”如果看到类似Scouter Java Agent initialized...和Connected to collector的日志说明Agent已成功启动并连接到Server。3.4 Host Agent部署与配置在同一台应用服务器192.168.1.100上我们还需要部署Host Agent来监控OS资源。解压并部署tar -xzf scouter.agent.host-*.tar.gz mv scouter.agent.host /usr/local/ cd /usr/local/scouter.agent.host配置Host Agent编辑conf/scouter.conf。net_collector_ip192.168.1.200 net_collector_tcp_port6100 net_collector_udp_port6100 obj_nameprod-host-100 # 主机名建议包含IP或业务标识 obj_typehost # 必须与Server端定义的obj_type_ext匹配 # 进程监控可以监控指定的Java进程并与Java Agent对象关联 # 通过进程名或PID文件来匹配 monitor_process_patternjava # 监控所有包含‘java’的进程 # 或者更精确地指定PID文件 # monitor_process_pid_file/var/run/tomcat.pid启动Host Agent./host.sh start使用./host.sh status检查运行状态使用./host.sh stop停止。3.5 通过Telegraf监控MySQL为了监控MySQL我们在应用服务器上使用Telegraf。安装Telegraf根据你的Linux发行版安装Telegraf例如Ubuntuapt-get install telegraf。配置Telegraf编辑/etc/telegraf/telegraf.conf启用inputs.mysql插件并配置outputs.socket_writer指向Scouter Server。[[inputs.mysql]] servers [tcp(127.0.0.1:3306)/] # MySQL连接地址 username telegraf # 创建一个仅用于监控的数据库用户 password your_secure_password # 收集的指标集 metric_version 2 gather_all true # 收集所有可用指标 [[outputs.socket_writer]] address tcp://192.168.1.200:6100 # 指向Scouter Server data_format influx # Scouter Server的Telegraf接收器支持Influx格式记得在MySQL中创建相应用户并授予PROCESS, REPLICATION CLIENT, SELECT权限。在Scouter Server端配置对象识别为了让Scouter Server正确识别Telegraf发来的MySQL数据我们需要在Server的scouter.conf中确保有对应的对象类型前面已定义obj_type_ext_3mysql并且Telegraf发送的数据中需要包含能标识对象类型的Tag。Scouter的Telegraf接收器通常会根据输入插件的名称自动映射类型如inputs.mysql-mysql类型。如果自动映射不生效可以在Telegraf配置中全局添加Tag[global_tags] objType mysql objHost prod-host-100 # 关联到主机重启Telegrafsystemctl restart telegraf3.6 Scouter Client连接与初体验在监控服务器或你的个人电脑上启动Scouter Client。解压并启动解压客户端压缩包直接运行可执行文件如scouter.exe。连接Server启动后在主界面点击“文件”-“新建服务器连接”。别名任意如“生产环境监控中心”地址192.168.1.200 Scouter Server的IP端口6100用户名/密码默认空如果Server端未配置认证查看监控数据连接成功后左侧对象树会逐渐出现你配置的tomcat和host对象。你可以双击对象进入详细视图。打开“实时仪表盘”查看全局状态。打开“XLog”视图选择你的Tomcat对象就能看到实时的请求散点图。刚开始可能没数据访问一下你的Web应用就会产生请求日志。至此一个基础的Scouter监控系统就搭建完成了。你已经在监控一个Java应用及其所在的主机并且具备了扩展监控MySQL的能力。4. 核心功能实战性能问题排查全流程部署只是第一步真正体现Scouter价值的是用它来发现和解决实际问题。下面我模拟一个典型的性能问题排查场景。场景描述市场部门报告在每天上午10点的促销活动开始后订单提交页面的加载速度极慢有时甚至超时。4.1 第一步全局视野定位问题对象打开Scouter Client进入“实时仪表盘”或“对象列表”视图。在活动开始后观察所有tomcat类型对象的指标。你可能会立刻发现一个名为prod-order-service-01的Tomcat实例其响应时间Avg Response Time图表飙升到数秒TPSTransactions Per Second下降并且活动服务计数Active Service持续处于高位。同时观察对应的host对象。你可能会发现该服务器的CPU使用率或系统负载也同步飙升甚至内存使用率居高不下。实操心得在仪表盘视图中我会习惯性地将关键对象的“响应时间”和“TPS”图表并排放在一起。响应时间上涨伴随TPS下降通常是应用内部阻塞或资源耗尽如果响应时间上涨但TPS也上涨则可能是达到了系统处理能力的瓶颈。4.2 第二步下钻分析揪出慢请求在对象列表或仪表盘中双击那个有问题的prod-order-service-01对象进入其专属视图。切换到“XLog”标签页。这是一个散点图每个点代表一个请求X轴是时间Y轴是响应时间。在问题时间段上午10点后你会看到大量高点慢请求聚集。将鼠标悬停在某个高点上会显示该请求的URL、响应时间、状态码等概要信息。关键操作直接用鼠标框选这些高点区域。Scouter会列出这个时间段内所有被选中的请求。从列表中选择一个响应时间最长的请求右键点击选择“Profile”或直接双击。这将打开本次请求的详细调用栈剖析。4.3 第三步剖析调用栈定位瓶颈代码在打开的Profile视图中你会看到一个树状结构的方法调用列表。这是Scouter通过字节码增强捕获的完整执行路径。看顶层最顶层的通常是HTTP请求入口比如Servlet.service()。它的总耗时就是这次请求的响应时间。找耗时大户逐层展开寻找耗时占比最大的子方法。Scouter会清晰地显示每个方法的“自耗时”该方法自身代码耗时和“总耗时”包含其调用的所有子方法耗时。假设你发现一个名为OrderService.calculateDiscount()的方法总耗时占了80%。点击它查看详情。分析细节SQL剖析如果这个方法内部执行了SQL在Profile下方或单独的“SQL”标签页中你会看到具体的SQL语句、执行时间、返回行数。也许是一条没有索引的复杂查询或者发生了全表扫描。外部调用如果它调用了外部HTTP API或Redis也会被记录在这里。可能是一个外部服务响应变慢。方法自身逻辑如果排除了SQL和外部调用那问题很可能出在方法自身的业务逻辑上比如一个低效的循环算法或者发生了大量的GC。在我们的模拟场景中你很可能发现calculateDiscount方法里执行了一条类似SELECT * FROM user_coupons WHERE user_id? AND activity_id?的SQL而这条SQL在活动期间因为缺少复合索引(user_id, activity_id)导致执行缓慢。4.4 第四步关联资源视图确认系统瓶颈回到prod-order-service-01的对象视图查看“计数器”标签页。JVM内存与GC检查“堆内存使用率”和“GC时间”图表。如果发现堆内存使用率持续接近上限且Full GC频繁发生说明可能存在内存泄漏或堆空间设置过小。频繁的GC会“Stop The World”直接导致应用暂停所有请求变慢。线程状态查看“活动线程数”和“死锁线程数”。如果活动线程数飙升至接近线程池最大值且大量线程处于BLOCKED或WAITING状态说明存在线程竞争或锁等待。主机资源切换到关联的host对象视图确认CPU、磁盘I/O特别是等待时间await、网络是否成为瓶颈。例如如果磁盘I/O等待时间很高即使SQL本身没问题执行也会变慢。通过这四步你基本上可以从现象页面慢定位到具体原因慢SQL、内存GC、资源竞争等。Scouter提供的这种从宏观到微观、从指标到代码的完整视角是传统监控工具如Zabbix只监控系统指标难以比拟的。5. 高级配置与调优指南要让Scouter在生产环境稳定高效地运行一些高级配置和调优是必不可少的。5.1 Server端存储与性能调优Scouter Server默认使用内置的H2数据库存储时间序列指标使用文件存储XLog和Profile。对于高流量系统需要关注以下几点数据保留策略指标数据在scouter.conf中配置db_retention_policy。例如db_retention_policydaily:31,5m:7表示5分钟精度的数据保留7天日聚合数据保留31天。根据你的磁盘空间和查询需求调整。XLog/Profile数据这些是详细日志体积增长很快。配置xlog_keep_days和profile_keep_days来控制保留天数通常设置为3-7天。更早的数据可以配置自动清理脚本。JVM参数调优Scouter Server本身也是Java程序。在startup.sh或直接启动时可以调整JVM参数。# 示例增大堆内存使用G1垃圾回收器 java -Xms2g -Xmx2g -XX:UseG1GC -XX:MaxGCPauseMillis200 -jar scouter-server-boot.jar-Xms2g -Xmx2g将堆内存初始和最大值都设为2GB避免运行时动态调整。-XX:UseG1GC对于需要较低延迟的监控服务G1收集器通常比默认的Parallel GC更合适。监控Server自身的GC日志确保没有频繁的Full GC。网络缓冲区如果Agent数量众多上百个可能需要调整Server的Socket缓冲区大小在scouter.conf中配置net_tcp_so_rcvbuf_size和net_udp_so_rcvbuf_size单位字节例如设置为10485761MB。5.2 Java Agent深度配置采样率控制全量采集所有请求的Profile对性能有影响。生产环境可以设置采样率。# 全局采样率1.0为100% 0.01为1% profile_sampling_rate0.1 # 对慢请求超过阈值的仍然100%采样 profile_service_ms_threshold3000这样只有10%的普通请求和所有超过3秒的慢请求会被详细剖析在开销和问题捕获之间取得平衡。过滤特定请求有些请求如健康检查/health、监控端点/metrics不需要被监控。# 忽略特定URL模式的请求 trace_ignore_url/health, /metrics, /static/*自定义业务监控Scouter提供了API允许你在业务代码中手动记录关键指标。import scouter.lang.counters.CounterConstants; import scouter.lang.pack.PerfCounterPack; import scouter.server.Logger; import scouter.util.CastUtil; public class BusinessMonitor { public static void addOrderCount(int count) { try { PerfCounterPack pack new PerfCounterPack(); pack.time System.currentTimeMillis(); pack.objName AgentModel.getAgentObjectName(); // 获取当前对象名 pack.timetype 0; // 实时数据 // 使用自定义计数器ID需要在client端定义视图 pack.put(CounterConstants.USER_DEFINE_1, CastUtil.cdouble(count)); // 发送到Server // ... (通过Agent线程上下文发送) } catch (Exception e) { Logger.println(A102, BusinessMonitor error: e.getMessage()); } } }这需要更深入的集成但能实现业务指标如每分钟订单数、库存变化的监控。5.3 告警规则配置实战Scouter的告警规则在Server端的conf/scouter.conf中配置语法灵活强大。一个典型的告警配置示例# 定义一个名为‘high_cpu’的告警规则 alert_rule_high_cpu_enabledtrue alert_rule_high_cpu_object_typehost # 对host类型对象生效 alert_rule_high_cpu_countercpu # 监控的计数器是CPU使用率 alert_rule_high_cpu_conditionvalue 80 # 条件值大于80% alert_rule_high_cpu_check_period10 # 检查周期10秒 alert_rule_high_cpu_continue_count3 # 连续3次满足条件才触发持续30秒高CPU alert_rule_high_cpu_levelWARN # 告警级别WARN alert_rule_high_cpu_title主机CPU使用率过高 # 告警标题 alert_rule_high_cpu_message主机 {objName} 的CPU使用率在过去30秒内持续超过80%当前值为 {value}%。 # 消息模板支持变量 # 定义一个慢服务告警 alert_rule_slow_service_enabledtrue alert_rule_slow_service_object_typetomcat alert_rule_slow_service_counterservice_avg_time # 服务平均响应时间 alert_rule_slow_service_conditionvalue 5000 # 平均响应时间超过5秒 alert_rule_slow_service_check_period60 # 每60秒检查一次看1分钟内的平均值 alert_rule_slow_service_continue_count1 alert_rule_slow_service_levelERROR alert_rule_slow_service_title服务响应时间过长 alert_rule_slow_service_message服务 {objName} 的平均响应时间在过去1分钟内超过5秒达到 {value} ms。请检查应用性能或依赖服务。配置好规则后需要启用告警输出。例如使用邮件插件将scouter-plugin-server-alert-email.jar放入Server的plugins目录。在conf/scouter.conf中配置SMTP信息ext_plugin_alert_email_enabledtrue ext_plugin_alert_email_smtp_hostsmtp.gmail.com ext_plugin_alert_email_smtp_port587 ext_plugin_alert_email_smtp_authtrue ext_plugin_alert_email_smtp_usernameyour_emailgmail.com ext_plugin_alert_email_smtp_passwordyour_app_password # 注意使用应用专用密码 ext_plugin_alert_email_fromyour_emailgmail.com ext_plugin_alert_email_toteam-alertsyourcompany.com ext_plugin_alert_email_subject_prefix[Scouter Alert]重启Scouter Server。当规则触发时告警邮件就会被发送。6. 常见问题与故障排查实录在实际使用中你肯定会遇到各种问题。下面是我踩过的一些坑和解决方法。6.1 Agent连接不上Server症状Agent日志中不断打印连接失败或超时的错误。排查步骤网络连通性在Agent服务器上执行telnet server_ip 6100或nc -zv server_ip 6100检查端口是否通。防火墙确认Server服务器的6100端口是否对Agent服务器开放。检查iptables、firewalld或云服务商的安全组规则。Server状态确认Scouter Server进程是否正常运行查看Server日志logs/scouter.log有无错误。配置错误仔细核对Agent配置scouter.conf中的net_collector_ip和net_collector_tcp_port确保没有拼写错误且IP地址是Server的真实IP不是127.0.0.1或localhost。6.2 Client连接Server后看不到数据症状Client能成功连接Server但对象列表为空或者对象有但所有指标都是0。排查步骤对象类型匹配这是最常见的原因。确保Agent配置中的obj_type如tomcat与Server配置中定义的某个obj_type_ext_N的值完全一致大小写敏感。Agent日志查看Java Agent或Host Agent的日志确认是否有Connected to collector的成功日志以及是否有数据发送的日志。Server日志查看Server日志看是否有接收到来自Agent的连接和数据包。搜索Agent的obj_name。时间同步确保Server和所有Agent服务器的时间基本同步NTP。时间不同步可能导致数据在Client上显示异常。6.3 Profile方法剖析数据不显示或不全症状在XLog视图中点击请求Profile页面是空的或者调用栈非常浅。排查步骤采样率与阈值检查Agent配置中的profile_sampling_rate和profile_service_ms_threshold。可能因为采样率太低或请求没达到慢阈值导致没有采集详细Profile。过滤规则检查trace_ignore_url或trace_ignore_method配置是否不小心把要监控的URL或方法过滤掉了。字节码增强兼容性某些特殊的框架、动态代理或字节码操作库如CGLIB、ASM的高版本可能与Scouter的字节码增强冲突。尝试更新Scouter Agent到最新版本或者在启动参数中排除某些包-Dscouter.asm.exclude.packagescom.some.problematic.package.*。Profile数据保留确认Server的profile_keep_days设置是否太短导致历史数据已被清理。6.4 监控开销过高症状部署Scouter Agent后应用本身的性能有明显下降如响应时间增加5%以上。优化措施降低采样率将profile_sampling_rate调低例如从1.0调到0.1或0.01。减少SQL细节采集关闭profile_fullstack_sql_enabled或者通过trace_sql_ignore过滤掉不重要的SELECT语句。调整缓冲区适当增大Agent的发送缓冲区net_udp_send_buffer_size减少网络发送频率但会增加少量内存消耗。升级硬件/网络如果Agent和Server之间的网络延迟很高也会间接增加开销。确保网络质量。隔离监控Server不要将Scouter Server部署在与核心业务竞争资源的机器上。6.5 数据堆积与磁盘空间告急症状Server所在磁盘空间使用率快速增长。解决方案调整保留策略立即检查并缩短db_retention_policy、xlog_keep_days、profile_keep_days。清理历史数据Scouter提供了清理工具。可以手动删除database/目录下过期的.idx和.log文件需在Server停止时操作或者编写定时任务脚本。使用外部存储对于大规模部署考虑使用scouter-plugin-server-influxdb插件将指标数据转发到InfluxDB集群利用其可扩展的时序数据库能力。Scouter Server自身只保留最近几天的热数据用于实时查询。监控Server自身为运行Scouter Server的主机也部署Host Agent监控其磁盘空间并设置告警。6.6 与第三方系统集成问题症状Telegraf数据在Scouter中不显示或者告警插件不工作。排查步骤Telegraf数据首先在Telegraf服务器上使用telegraf --test命令验证inputs插件是否能正常采集到数据。然后使用nc或tcpdump命令检查数据是否确实发送到了Scouter Server的6100端口。最后检查Scouter Server日志看Telegraf接收器是否解析了数据。告警插件确认插件JAR文件已正确放入plugins/目录且文件名正确。检查Server日志中是否有插件加载成功的记录。仔细核对插件所需的配置项如SMTP密码、Slack Webhook URL是否正确无误特别是含有特殊字符时是否需要转义。Scouter作为一个功能全面且高度可定制的开源APM其学习曲线相对平缓但深入使用后能带来的价值是巨大的。它不仅能帮你快速灭火解决线上故障更能通过长期的数据趋势分析帮助你进行容量规划、性能优化和架构改进。从最初的“救火队员”到后来的“系统保健医生”Scouter可以成为你技术工具箱中一件非常得力的武器。