NodeJS CPU 占用100%问题排查

上周接到同事反馈,客户服务器不时出现 502 错误,需要定时重启前端服务。上服务器上看了一下 cpu 占用100%,无法响应请求,由于是生产系统,备份了一下日志,重启服务。 疑似 ddos 攻击 看了一下日志,由于应用日志是 warning 级别,并没有太多有用信息,倒是 nginx 日志有大量的无效访问,并且这些访问大部分都是由 100.97. »

基于容器的分布式日志收集

0. 基础方案:ELK 大规模系统,特别是分布式系统中,服务化、容器化、运维自动化带来了运维的便利,但是相应的代价是系统复杂性上升,开发人员将面对种种复杂情况的挑战。 其中日志的离散将导致调错成本进一步上升,分布式日志的集中收集处理可能是这一问题的解决之道。 业界有多重面向容器的日志解决方案,不再一一复述,ELK 因为其开源且接受过实战考验,作为我们的日志收集方案之一。 ELK 的架构就不展开详解了,因为关于这方面的文章已经有很多,他的总体思路就是: Logstash(采集) -> Elasticsearch(储存) »

一次纠结的线上问题排查之应用优化

这次旷日持久的web 502问题终于画上了句号,在此总结一发,以表纪念与反思。 起因 客户在年前就已经反应网站经常502,当时还有开发任务没太在意,所以每次502就直接重启服务解决。直到年后,批量操作新功能上线,502问题就非常频繁了,几乎一天一次! 在这里自我检讨一下,对问题没有足够的重视也没有足够的警觉,自身处理这类问题的能力也需要加强。 经过 经过各路大神的分析与调试,这是分析过程, 发现是踩到了曾经的一个坑,鉴权拦截器里有用到GuavaCache,没有设置MaxSize和过期时间,而且每次前端请求发过来,cache的key都会重新new一把,导致重复积累对象,内存得不到释放,最后OOM了。 »

Kotlin 随手记(一): InfluxDB Client 查询封装思路

1. 关于 InfluxDB-JAVA InfluxDB 是 InfluxData 公司的一款开源时间序列数据库,多用于储存日志、持续事件、监控数据之类时间相关的序列化数据。并提供了多种语言的接入方式,并且官方提供了 Java client: inflxudb-java,Kotlin 项目可以直接引入依赖并且使用。 2. 接入方式 InfluxDB 使用 RESTful 接口来查询与写入,官方 Client 便在 »

一次纠结的线上问题的排查

上周五接到一个任务, 说某个客户的一个线上java应用挂了, 现象就是cpu飙升, 几乎跑满, 无法响应请求。ssh连上去看了看应用日志, 有大量的java.lang.OutOfMemoryError: Java heap space 这种类型的日志, 看了看jvm启动参数, 给的比较小, 于是没放心上, 那就分配多一点jvm内存, 周末观察一下再说. 这里需要检讨一下, 调大内存的时候, 就应该加上-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=...., 这样内存溢出的时候就可以分析内存快照。 修改了参数后, »

Terminus Actuator:分布式监控(一)

简介 监控工具内置了 Servlets、Jetty、mybatis、redis 和基于 AOP 的 Spring component 监控,并定时将数据写入 InfluxDB。 监控工具基于 Dropwizard 进行了再封装,加入了额外的模块名、机器信息和 TerminuKey 等,以适应端点的分布式电商体系。 接入方式 为了使用监控,联系管理员获取 TerminusKey, »