基础设施监控:主要对各个微服务实例所在的基础设施进行监控,具体包括这些设施的运行状态、资源使用情况及系统日志进行监控,一般而言微服务应用实例会运行在容器里,因此这个维度的监控对象也通常包含有容器编排系统、持续构建系统、镜像仓库等,这些对象的具体监控指标的范围包括对象的健康状态、运行状态、资源使用情况等;
微服务通用监控:主要针对微服务通用指标进行监控,包括服务实例处理请求的情况及实例调用其它服务的情况,具体而言包括请求总数、请求处理时延(中位数,包括有90、95和99值)、请求结果(成功、失败、熔断、限流、超时和拒绝)统计、调用其它服务的结果(成功、失败、熔断、限流、超时和拒绝)统计及时延(中位数,包括有90、95和99值);
应用监控:主要对具体的微服务实例进行性能监控,通过数据自动化收集、数据可视化展示,使用户能够及时、全面地掌控各个实例的性能情况,定位性能瓶颈。这一维度重点在于提供丰富的应用性能展示及性能问题定位功能,包括应用响应时间、吞吐量和状态的展示,慢响应和错误明细的查询。
通用中间件:我们没有预置这个维度的监控到系统里,不过得益于Prometheus完善的生态,系统保留有对常用数据库、消息队列及缓存进行监控的能力,具体包括MySQL、Redis、Memcached、Consul、RabbitMQ及Kafka等。
————————————————
版权声明:本文为CSDN博主「C站训练营学员C站训练营学员C站训练营营」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接 网易轻舟监控:https://blog.csdn.net/cpongo3/article/details/89027227
内网安全监控和预警平台架构设想
需求简介
内网安全监控和预警平台是内网安全建设的物质基础,是所有甲方安全建设的必备武器库,无论是应急响应和追踪溯源,还是预知告警、自我清查;做下来总的体会是几个问题永远挥之不去,阴魂不散:
- 资产不清(尤其是资产对应的负责人员和业务特点不明确)
- 监控不全(对流量覆盖度不够,日志配置和收集不够,应急响应和追踪溯源的时候查不到、查不清、查一半等问题突出)
- 探测不到(这里主要指主动探测发现漏洞和风险的能力较差、规则和情报的积累和使用问题)
而且就在这种情况下,依然使得内网安全运营的的数据量达到人工难以分析的程度,因此对整体OSSIM体系建立就是十分必要的。
能力体系
想做到这些需要具备一些能力基础,如下图:
最顶层是自己的业务需求,中间的大数据分析能力是开发的系统的能力、安全基础能力是自身安全团队的知识经验能力以及购买的技术能力(规则库、病毒库、威胁情报、自动处置响应能力等)
最下层的是最基本的建设需求,流量的全覆盖、日志的全收集、蜜网蜜罐、监控点、扫描点、堡垒机、IDS、审计设备等。
架构体系
资产收集
NIDS
HIDS
漏洞监控
总体架构体系
需要的能力值
- NIDS:完整的记录五元组、可以分析应用层payload,完整还原流量(协议解析)、保存流量;
- HIDS:进程、服务、注册表、命令记录、关键文件的创建与改动时间,主机网络流量情况等;
- 日志能力:shell-log、access-log、app-log、login-log,sec-log,db-log、恶意程序、文件、下载运行日志等;