jmtt 出问题，第一步不是重启，而是看日志。绝大多数异常都有可追溯的根因：配置漂移、端口冲突、资源超限或依赖项版本不兼容。下面按「先软后硬、先近后远」的顺序，列出最常见的 12 类故障及其排查路径。
一、启动与运行类故障
- jmtt 启动时报「端口已被占用」，怎么确认并释放？
-
先用
netstat -tlnp | grep <端口号>（Linux）或netstat -ano | findstr :<端口号>（Windows）确认占用进程的 PID。若是系统关键进程（如 systemd、cron）占用了非必要端口，修改 jmtt 的配置让它监听另一个端口更安全；若是残留的旧进程，用kill -9 <PID>或任务管理器强制结束后再启动。若怀疑是端口未完全释放（TIME_WAIT 状态），可临时执行
sysctl -w net.ipv4.tcp_tw_reuse=1（Linux）缓解，但根本解法是更换端口或调整服务重启时序。 - jmtt 启动后立即退出，看不到任何报错信息怎么办？
-
这种情况通常是静默崩溃，优先检查以下三个地方：
- systemd 日志：
journalctl -u jmtt --no-pager -n 50，看最后 50 行是否有段错误信号。 - 配置文件语法：用
jmtt --config-check（如有该参数）或手动打开配置文件，检查括号、引号、缩进是否配对。 - 权限问题：jmtt 运行时若需要写入某个目录，确认运行用户对
/var/log/jmtt、/run/jmtt等路径有写权限。
- systemd 日志：
- 首次部署 jmtt 时数据库连接失败，可能的原因有哪些？
-
常见原因有三类，按出现频率排序：
现象 最可能原因 验证方法 连接超时 数据库服务未启动或防火墙拦截 telnet <DB_HOST> <端口>认证失败 用户名/密码错误，或目标库不存在 手动 mysql -u root -p验证SSL 握手失败 jmtt 要求 SSL，但数据库未配置证书 在连接字符串末尾加 ?sslmode=disable测试 - jmtt 启动后 CPU 占用率异常飙升，如何定位是哪个模块导致的？
-
按以下三步收敛：
- 用
top -p $(pgrep -f jmtt)或htop确认是单个线程还是多进程异常。 - 用
jmtt-admin dump-threads导出当前线程栈，找「RUNNABLE」状态中占比最高的线程名。 - 对照线程名匹配对应功能模块（如调度器、IO 线程池），定位到具体配置文件里的参数调优项。
多数情况下是调度参数设置过大导致线程饥饿，把并发线程数回退到上一版本基准值即可恢复。
- 用
二、性能与运行时异常
- jmtt 运行一段时间后响应变慢，如何判断是内存泄漏还是外部依赖拖慢？
-
做一个简单区分：
内存泄漏查看 jmtt 进程的 RSS 是否在每次请求后持续上涨而不再回落，连续采集 5 次，间隔 10 分钟，若单调递增且回收不明显则大概率是泄漏。
外部依赖拖慢查看 jmtt 的慢查询日志或访问链追踪，若某次调用耗时集中在数据库、消息队列或第三方 API，则是依赖方响应变慢，应在对应服务的监控面板（如 Prometheus、Grafana）上交叉验证。 - jmtt 在处理大批量数据时频繁报「内存溢出」，怎么优化？
-
分批处理是最直接的方案。把单次处理量控制在配置项
jmtt.batch.size的推荐值以内（通常 ≤ 5000 条），并开启jmtt.gc.threshold让 JVM 在堆占用超过阈值时提前触发 GC，避免全量堆积后 OOM。
若业务确实需要大批次吞吐，考虑把 jmtt 的运行内存上限从默认的 1G 调到 2G-4G（修改JAVA_OPTS=-Xmx），同时配合-XX:+UseG1GC启用 G1 收集器，减少 Full GC 停顿时间。 - jmtt 与下游系统通信中断，如何判断是网络问题还是 jmtt 自身异常？
-
用
ping和traceroute 先确认基础连通性；再用curl -v http://<下游>/health测试下游健康检查端点。如果 ping 正常但 curl 返回超时，检查防火墙规则和 jmtt 的代理配置（jmtt.proxy.host）是否指向了错误的出口 IP。
若两者都失败，登录下游系统查看其自身的运行日志，排除下游主动断连的可能。jmtt 侧也可开启 TCP 重试日志：jmtt.net.retry.log=true，方便回溯断线次数和原因码。 - jmtt 定时任务未按预期触发，应该怎么检查？
-
按以下优先级逐项核对：
- 任务状态：在管理界面确认任务处于「启用」而非「暂停」状态。
- Cron 表达式：用在线工具或
jmtt cron expr命令验证表达式是否被正确解析。 - 时区差异：服务器时区与任务配置的时区不一致是最常见的原因，执行
timedatectl查看并统一为Asia/Shanghai。 - 依赖锁定：如果前一个任务因异常卡住，后续任务会被阻塞，先清理事件队列再观察。
- jmtt 升级后某个功能无法使用，是配置丢了还是版本不兼容？
-
升级后首做两件事：
① 对比升级前后的jmtt.conf，用diff找出新增或删减的参数；
② 查看 jmtt 官方的CHANGELOG，确认被停用的功能是否在本次大版本中被迁移或废弃。
若参数被删除，从备份配置中复制回来并执行jmtt migrate-config完成格式转换，再重启服务。
三、日志与监控类问题
- jmtt 日志文件过大导致磁盘告警，该怎么清理而不影响追溯？
-
启用日志轮转（logrotate）是正规做法。在
/etc/logrotate.d/jmtt配置文件中设定：
rotate 7（保留 7 份）、daily（每日轮转）、compress（压缩旧文件）、size 100M（单文件超 100M 即触发）。
紧急清理时，不要直接rm正在写入的日志，而是用truncate -s 0 /var/log/jmtt/app.log清空，避免进程文件句柄未释放仍占用磁盘。 - jmtt 告警频繁触发，但人工排查后一切正常，如何区分真实告警和误报？
-
记录连续 3 天的告警日志，提取规律：若告警集中在业务低峰期且伴随阈值波动，大概率是告警阈值设得过紧。将原阈值的上下限各放宽 20%（如 CPU > 85% 改为 > 90%），并给每个告警规则添加
consecutive-durations条件——连续 2 个周期仍超标才真正告警，有效过滤瞬时抖动。 - jmtt 接入 Prometheus 后指标数据缺失，如何排查？
-
按以下清单逐项检查：
- jmtt 的暴露端口是否已加入 Prometheus 的
scrape_configs白名单。 - 防火墙是否放行了 jmtt 指标端口（默认 9100）的入站流量。
- jmtt 服务发现标签（instance、job）是否与 Prometheus 期望的格式一致。
- 用
curl http://<jmtt-host>:9100/metrics直接访问，确认返回内容不为空。
- jmtt 的暴露端口是否已加入 Prometheus 的
四、安全与权限问题
- jmtt 登录后会话频繁过期，是会话配置问题还是安全策略限制了？
-
两种情况需要分开排查：先看 jmtt 的
session.timeout配置值是否过短（默认 30 分钟较常见），将其改为 2 小时以上即可缓解；再看是否启用了 IP 绑定或并发会话限制，若有，确认操作者是否使用了 NAT 出口导致 IP 抖动，或同一账号在多台设备登录触发了并发上限。修改后可在管理后台的「会话管理」面板实时观察。 - jmtt 报「权限不足」但管理员账号也无法操作，怎么回事？
-
首先确认你登录的账号确实拥有管理员角色（在用户管理页核对），其次检查 jmtt 的 RBAC 策略是否误删了管理员组的权限节点。执行
jmtt-admin reset-permissions admin恢复默认角色权限，如果仍无效，尝试重建管理员账户并重新绑定角色。
部分情况下是数据库中的用户映射表与 jmtt 应用层不同步，执行jmtt-admin sync-users强制同步一次。 - jmtt 运行日志中出现「Unauthorized」报警，是否意味着遭到了入侵？
-
不一定。先统计报警来源 IP 的分布：如果是少数几个固定 IP 反复触发，很可能是某个内部服务的 token 已过期但未刷新；如果是大量不同 IP，则要提高警惕，立即在防火墙侧临时封禁这些 IP 段，并检查 jmtt 的登录接口是否暴露到了公网。
无论哪种情况，都应在/getting-started/页面的安全基线检查清单中对照，确认 jmtt 已启用 HTTPS 和强密码策略。
还没找到你遇到的问题？查看完整的问题排查索引，或到工具资源页获取诊断脚本。
进入工具资源 →几点观察
整理这 12 类常见故障时发现一个规律：超过一半的问题源于配置变更没有经过灰度验证。jmtt 的很多参数在升级或迁移后会悄悄回到默认值，导致行为与预期产生偏差。
建议每次修改 jmtt 配置前，先在 /how-to/ 提到的测试环境做一次完整的冒烟测试，确认核心路径（启动、调度、通信、写入）都正常后再推到生产。对于线上问题，养成「先看日志、再看配置、最后重启」的习惯，能避免 90% 的盲目操作。
如果你在实际排查中遇到了这里没有覆盖的场景，欢迎通过 business@lhl537.cn 反馈，我们会持续更新本篇内容。