在 Ubuntu 维护 Java 应用时，日志监控通常不是“要不要做”的问题，而是“先用什么做、做到什么程度”。这篇文章把常见方案按排障速度、可观测范围和部署复杂度拆开说明：先看命令行怎么快速定位问题，再看 ELK、Prometheus + Grafana、Sentry 这类平台分别解决什么场景，最后补上 logrotate 这一步，帮助你判断一套方案能不能长期跑稳。
命令行监控：先解决实时查看和快速定位
如果当前目标是排查故障、确认应用是否持续报错，命令行通常是最快的入口。在 Ubuntu 上，这一层主要解决两件事：实时跟踪新增日志，以及从大量文本里尽快筛出关键信息。
四个最常用的日志查看命令
tail：适合盯住最新输出，观察应用是否持续打印异常。实时跟踪文件新增内容：
tail -f /path/to/java.log查看最后 100 行：
tail -n 100 /path/to/java.log实时查看时可按
Ctrl+C停止。grep：适合按关键字筛选异常、告警或某个业务字段。筛选错误：
grep "ERROR" /path/to/java.log忽略大小写查找 warning：
grep -i "warning" /path/to/java.logless：适合查看大体积日志文件，尤其是回看历史记录时更方便。less /path/to/java.log进入后可用
Page Up/Page Down翻页，按q退出。journalctl：适合通过systemd方式运行的 Java 服务，不必直接找日志文件。如果应用由
systemctl start my-java-app启动，可以这样实时查看：journalctl -u my-java-app -f查看指定日期后的日志：
journalctl -u my-java-app --since "2025-09-26"
这一类工具的优势是上手快、零额外部署，适合开发环境、临时排查和单机问题定位。但它们不擅长长期保存、跨服务搜索和图形化分析，一旦日志量上来，就需要引入更完整的平台。
集中化日志平台：适合长期留存、统一搜索和可视化分析
当 Java 应用进入生产环境，日志监控往往不再只是“看一眼文件”。你可能需要跨时间范围检索、统一保存多台机器日志、按字段做过滤，甚至直接在图表里观察错误波动。这时更常见的方案是 ELK Stack 或 Graylog。
ELK Stack：从采集到可视化的一条链路
ELK Stack 由 Elasticsearch、Logstash、Kibana 组成：
- Elasticsearch：负责日志存储与索引。
- Logstash：负责采集、解析和处理日志。
- Kibana：负责搜索界面和图形化展示。
如果你希望把 Java 日志接入 ELK，可以按下面的步骤配置。
安装 Elasticsearch、Logstash 和 Kibana
先添加 Elasticsearch 软件源并安装：
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo apt-key add -
echo "deb https://artifacts.elastic.co/packages/7.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-7.x.list
sudo apt update && sudo apt install elasticsearch安装 Logstash：
sudo apt install logstash安装 Kibana：
sudo apt install kibana配置 Logstash 采集 Java 日志
创建配置文件 /etc/logstash/conf.d/java.conf，示例内容如下：
input {
file {
path => "/path/to/java.log"
start_position => "beginning"
sincedb_path => "/dev/null"
# 首次运行时忽略已读记录
}
}
filter {
grok {
match => {
"message" => "%{TIMESTAMP_ISO8601:timestamp} %{LOGLEVEL:loglevel} %{GREEDYDATA:logmessage}"
}
}
# 根据日志格式调整 grok 模式
date {
match => ["timestamp", "ISO8601"]
}
}
output {
elasticsearch {
hosts => ["localhost:9200"]
}
stdout {
codec => rubydebug
}
# 控制台输出，调试用
}这段配置的核心点有三个：一是从指定文件读取 Java 日志；二是用 grok 拆出时间、级别和正文；三是把结果写入本机的 Elasticsearch。实际使用时，grok 模式通常需要按你的日志格式微调。
启动服务并访问 Kibana
sudo systemctl start elasticsearch
sudo systemctl start logstash
sudo systemctl start kibana服务启动后，可以访问 http://localhost:5601 打开 Kibana 界面，进行搜索、筛选和可视化分析。
Graylog：更偏日志聚合与告警
Graylog 也是常见的开源方案，支持日志聚合、实时搜索和告警能力。对于希望快速搭建统一日志入口、并结合安全事件管理的团队，它是 ELK 之外的另一条路线。原理上也类似：把 Java 应用日志统一发送到平台，再在页面里完成检索和分析。常见做法是把 Java 应用按 GELF 格式接入 Graylog，具体安装与部署可按官方文档执行。
性能指标与异常跟踪：日志之外还要看 JVM 状态
如果只是查看文本日志，你能知道“发生了什么”；但很多线上问题还需要回答“为什么会发生”。例如内存是否持续升高、GC 是否异常频繁、线程是否出现阻塞，这些都需要指标系统配合。这里更适合用 Prometheus + Grafana；如果关注的是异常聚合与通知，则可以接入 Sentry。
Prometheus + Grafana：补齐 JVM 指标监控
Prometheus 负责采集 Java 应用暴露出的指标，Grafana 负责把这些指标做成图表和仪表盘。对 Java 服务来说，这类方案更适合观察 JVM 内存、GC 次数、线程等运行状态。
安装 Prometheus：
sudo apt install prometheus然后编辑 /etc/prometheus/prometheus.yml，在 scrape_configs 中添加 Java 应用的抓取目标。
如果你的项目是 Spring Boot，可以加入 Micrometer 的 Prometheus 依赖：
<dependency>
<groupId>io.micrometer</groupId>
<artifactId>micrometer-registry-prometheus</artifactId>
<version>1.10.5</version>
</dependency>并在 application.properties 中开放对应端点：
management.endpoints.web.exposure.include=prometheus安装 Grafana：
wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://packages.grafana.com/oss/ubuntu $(lsb_release -cs) main" | sudo tee -a /etc/apt/sources.list.d/grafana.list
sudo apt update && sudo apt install grafana
sudo systemctl start grafana-server启动后访问 http://localhost:3000，默认账号为 admin/admin。接下来导入 Prometheus 数据源并创建仪表盘，就可以持续观察 Java 应用的运行指标。
Sentry：更专注异常收集与通知
如果你的重点是错误跟踪，而不是完整指标体系，Sentry 会更直接。它适合集中收集 Java 应用异常、汇总堆栈信息，并向开发者发送通知。
自托管安装流程如下：
git clone https://github.com/getsentry/self-hosted.git
cd self-hosted && ./install.sh
docker-compose up -d部署过程中还需要按实际需求调整 config.yml，例如邮件通知配置。相比单纯翻日志文件，Sentry 更适合处理“异常太多、需要按事件归并”的场景。
日志轮替：避免日志文件持续膨胀
无论前面用的是哪种监控方式，只要 Java 应用持续写日志，文件体积都会不断增长。没有轮替策略，磁盘空间迟早会被吃掉，排障效率也会变差。因此，logrotate 基本属于生产环境的必备项。
使用 logrotate 管理 Java 日志文件
可以为应用创建单独的轮替配置文件 /etc/logrotate.d/java-app：
/path/to/java.log {
daily
rotate 7
compress
missingok
notifempty
copytruncate
}daily：每天轮换一次。rotate 7：保留最近 7 份历史日志。compress：旧日志压缩保存。missingok：日志文件不存在时不报错。notifempty：空日志文件不轮换。copytruncate：复制原日志后清空，适合仍在写入的日志文件。
正式启用前，先做一次模拟检查：
sudo logrotate -d /etc/logrotate.d/java-app确认配置无误后，可以强制执行一次：
sudo logrotate -f /etc/logrotate.d/java-app如何组合这些方案
如果只是开发阶段临时排查，tail、grep、less 和 journalctl 已经足够高效；它们部署成本低，适合先把问题定位出来。进入生产环境后，如果你需要长期保存、统一检索和图形化分析，ELK 或 Graylog 更合适。
当关注点扩展到 JVM 内存、GC、线程等运行指标时，Prometheus + Grafana 能补上日志看不到的部分；如果团队更在意异常聚合、告警通知和错误回溯，Sentry 会更直接。至于 logrotate，它不属于“可选增强”，而是所有本地日志方案都应该尽早补上的基础设施。
换句话说，一套更实际的思路通常是：先用命令行解决眼前问题，再按业务规模补上集中化平台和指标系统，最后用日志轮替保证磁盘与历史文件可控。这样搭起来的 Ubuntu Java 日志监控体系，既能应对临时排障，也能支撑长期运维。
