linux服务器12台每台部署jar包日志如何查看

我记得上次我在办公室时，旧服务器突然宕机了。
我急得满头大汗，立刻抓起键盘就往机房跑。
幸运的是，日志文件仍然存在。
我一行一行的查看，终于找到了问题所在：意外的空指针异常。
那一刻我真是太高兴了！等等，那个服务器的注册表路径是我之前手动改的，不然根本找不到。

在Linux上检查日志确实是一个简单但麻烦的任务。
它很简单，因为它可以直接从命令行运行，但它很令人头疼，因为你必须记住一些关键路径。
比如我上一个项目，日志文件明明放在/var/log/appname下，但是新同事直接在/data/logs里找，花了很长时间。

使用 tail -f /var/log/myapp.log 查看日志是最常见的操作。
我记得去年冬天，凌晨三点，我收到一条警报，说用户报告系统宕机了。
我运行服务器扫描并逐行查看日志输出。
我发现数据库连接池已经耗尽。
当时屏幕上显示的最后一行是“2 02 3 -1 2 -03 03 :02 :1 5 ERROR pool Exeded”。
这是灭火的关键！
但有时单纯阅读原始日志是很困难的。
比如上周，系统报错，但是日志里全是堆栈信息，我很长一段时间都看不懂。
接下来，我使用 grep "ERROR" /var/log/myapp.log 并立即找到了问题代码。
这个技巧确实有效，尤其是当日志文件大小为数百 MB 时。

最烦人的是，当服务器出现问题时，日志路径可能会不同。
我记得有一次，当部署新版本时，日志路径从/var/log/app.log更改为/usr/local/logs/app.log。
结果我一直在老路下找，花了好长时间才找到。
我已经为此工作了很长时间，所以我真的必须记住使用 ps -ef | grep java 首先确认进程信息，检查环境变量中是否指定了注册表路径。

也就是说，现在很多项目都使用 ELK 堆栈。
直接在Kibana上搜索关键词真是太方便了。
即使是服务器管理员仍然需要了解一些 Linux 命令。
如果中间件出现问题，他们就不得不诉诸老办法。
就像我的朋友一样，他说所有问题都可以用Prometheus解决，但是当日志格式发生变化时，他感到很惊讶。

有时候阅读日志就像侦探破案一样。
比如前段时间我发现了一个奇怪的循环日志，每五分钟重复一条信息。
后来发现是注册表轮换脚本有问题，导致新的注册表文件覆盖了旧的文件。
如果你没有注意到这一点，系统迟早会崩溃。

如果你仔细想想，这些小技巧加起来就是简单的操作片段。
但当你真正遇到问题的时候，这些零碎的操作却可以拯救你。
正如我的老老师常说的，做一名系统管理员，必须具备“一针一线，一线之隔”的能力：无论问题有多大，你仍然能找到能拯救你的那根线。

多个jar包的日志如何监控

是的，这就是问题所在。
首先找到日志文件。

每个 JAR 的日志在哪里？查看配置文件。

使用vim或tail查看日志，使用tail -f进行实时监控。

Linux 在后台运行 JAR 并将日志存储在文件中。
哪个分布式系统？使用 SpringCloudSleuth 全连接跟踪。

你自己看看。
您还有其他问题吗？

linux启动jar包 文件无法查看

记得有一次，我将一个Java应用部署到公司服务器上，并用jar包启动。
因此启动后并没有生成日志文件。
我检查了路径、权限和启动方式，一切正常，但还是不行。
突然我想：jar包里的资源文件是不是没有被读取呢？于是我用InputStream读取配置文件，果然问题解决了。
等等，还有一件事，我突然想到，如果以后遇到类似的问题，我是否可以写一个脚本来自动检查这些常见问题？

JAVA运行JAR包及日志输出