webhook

alertmanager是通过命令行标记和配置文件配置的，命令行标记配置不可变的系统参数，配置文件定义抑制规则、通知路由和通知接收器。可以通过官方提供的 routing tree editor 查看配置的路由树详细信息 默认配置文件如下 [root@node00 ~]# cd /usr/local/prometheus/alertmanager/[root@node00 alertmanager]# cat alertmanager.yml.default global: resolve_timeout: 5m route: group_by: ['alertname'] group_wait: 10s group_interval: 10s repeat_interval: 1h receiver: 'web.hook'receivers:- name: 'web.hook' webhook_configs: - url: 'http://127.0.0.1:5001/'inhibit_rules: - source_match: severity: 'critical' target_match: severity: 'warning' equal: ['alertname', 'dev', 'instance'] 这个默认配置文件时通过一个webhook作为接受者

警报一直是整个监控系统中的重要组成部分，Prometheus监控系统中，采集与警报是分离的。 警报规则在 Prometheus 定义 ，警报规则触发以后，才会将信息转发到给独立的组件Alertmanager ，经过 Alertmanager r对警报的信息处理后，最终通过接收器发送给指定用户，另外在 Alertmanager 中没有通知组的概念，只能自己对软件重新Coding， 或者使用第三方插件来实现。 注意，这个通知组不是Alertmanager中的group概念，下面会详细讲 Group ，不要混淆哦。 前面已经介绍过一些关于 Alertmanager 知识点，本章开始针通过安装 Alertmanager 组件，对配置文件做详细说明，同时介绍 Prometheus 的警报规则的定义，最后使用Email、Wechat（Robot）、Dingtalk（webhook）来接受警报通知。 一、Alertmanager工作机制 在Prometheus生态架构里，警报是由独立的俩部分组成，可以通过上图很清晰的了解到 Prometheus 的警报工作机制。其中 Prometheus 与 Alertmanager 是分离的俩个组件。我们使用Prometheus Server端通过静态或者动态配置 去拉取 pull 部署在k8s或云主机上的各种类别的监控指标数据，然后基于我们前面讲到的

我们在钉钉上建立群聊，然后在群聊上添加钉钉机器人： 编写，脚本需要放在zabbix 的alertscripts目录下（如果不知道该目录的位置，可以使用find命令查找） find / -iname alertscripts 脚本 vim /usr/local/zabbix/alertscripts/ dingding.py # !/usr/bin/ env python #coding:utf - 8 #zabbix钉钉报警 import requests,json,sys,os,datetime webhook = " 上面创建钉钉机器人的webhook地址 " user =sys.argv[ 1 ] text =sys.argv[ 3 ] data = { " msgtype " : " text " , " text " : { " content " : text }, " at " : { " atMobiles " : [ user ], " isAtAll " : False } } headers = { ' Content-Type ' : ' application/json ' } x =requests.post(url=webhook,data=json.dumps(data),headers= headers) if os.path.exists( "

概念 简单来说，Sidecar 注入会 将额外容器 的配置 添加到 Pod 模板中 。这里特指将Envoy容器注应用所在Pod中。 Istio 服务网格目前所需的容器有： istio-init 用于设置 iptables 规则，以便将入站/出站流量通过 Sidecar 代理。 初始化容器与应用程序容器在以下方面有所不同： 它在启动应用容器之前运行，并一直运行直至完成。 如果有多个初始化容器，则每个容器都应在启动下一个容器之前成功完成。 因此，您可以看到，对于不需要成为实际应用容器一部分的设置或初始化作业来说，这种容器是多么的完美。在这种情况下， istio-init 就是这样做并设置了 iptables 规则。 istio-proxy 这个容器是真正的 Sidecar 代理（基于 Envoy）。 下面的内容描述了向 pod 中注入 Istio Sidecar 的两种方法： 使用 istioctl 手动注入 启用 pod 所属命名空间的 Istio Sidecar 注入器自动注入。 手动注入直接修改配置，如 deployment，并将代理配置注入其中。 当 pod 所属 namespace 启用自动注入后，自动注入器会使用准入控制器在创建 Pod 时自动注入代理配置。 通过应用 istio-sidecar-injector ConfigMap 中定义的模版进行注入。 自动注入

作者：Pawan Shankar 翻译： Bach （才云） 校对： bot （才云）、 星空下的文仔 （才云） 现在很多团队面临着这么一个挑战：如何在不减慢应用交付速度的情况下，管理好安全风险。有种方法可以解决该问题，就是 采用安全的 DevOps 工作流程 。 安全的 DevOps（也称为 DevSecOps）会在从开发到生产的整个应用程序生命周期中提供安全性以及监控功能，帮助我们交付安全、稳定和高性能的应用程序。如果我们把该工作流程插入现有的工具链中，可以为 DevOps、开发人员和安全团队最大程度地提高效率。 DevSecOps 五个基本工作流程包括镜像扫描、运行安全、合规性、Kubernetes 和容器的监控以及应用程序和云服务监控。 镜像扫描是嵌入到 DevSecOps 工作流程中的一项关键功能。作为第一道防线，它可以帮助我们在漏洞被利用之前检测到漏洞并阻止，另外，它还易于实现并可自动化。本文将介绍多个镜像扫描的最佳实践和技巧，帮助大家采用有效的容器镜像扫描策略。 K8sMeetup 什么是容器镜像扫描 镜像扫描是指分析容器镜像的内容和构建过程，以检测安全问题、漏洞或错误实践。 我们可以从多个 Feed（NVD、Alpine、Canonical 等）中收集“通用漏洞披露（CVE）”信息，以检查镜像是否容易受到***，其中有些还提供了开箱即用的扫描规则

B站视频链接 发明者量化交易平台扩展API最近升级了，升级支持了直接访问模式，这样就可以轻松实现TradingView报警信号发送给发明者量化交易平台机器人实现自动交易。如果小伙伴还不知道扩展API为何物，听我细细道来。 发明者量化交易平台扩展API 发明者API文档相关部分链接 扩展API的主要作用是给程序化操作发明者量化交易平台上的各种功能提供接口，例如同时批量启动机器人，定时机器人启动、停止，读取机器人信息详情等。我们使用发明者量化交易平台扩展API实现TradingView报警信号交易这个需求计划只用扩展API中的 CommandRobot(RobotId, Cmd) 接口即可，这个接口可以给指定ID的机器人发送交互指令，机器人接收到指令即可执行对应操作（例如下单买入、卖出等）。 要使用扩展API，首先需要创建自己的发明者账号的 API KEY : API KEY 秘钥由 access key 和 secret key 组成， API KEY 即程序化操作发明者量化交易平台的钥匙，所以一定要妥善保管，切勿泄露。 扩展API的直接访问模式 直接访问模式是指把 API KEY 直接写在URL的Query中，例如访问发明者量化交易平台扩展API的URL可以写成： https : //www.fmz.com/api/v1?access_key=xxx&secret_key=yyyy

本篇文章为系列文章，未读第一集的同学请猛戳这里： Spring Cloud 系列之 Config 配置中心（一） 本篇文章讲解 Config 如何实现配置中心自动刷新。 　　 配置中心自动刷新 　　 　　点击链接观看： 配置中心自动刷新视频 （获取更多请关注公众号「哈喽沃德先生」） 　　Spring Cloud Config 在项目启动时才会加载配置内容这一机制，导致了它存在一个缺陷，修改配置文件内容后，不会自动刷新。例如我们之前的项目，当服务已经启动的时候，修改 Github 上的配置文件内容，这时候，再次刷新页面，对不起，还是旧的配置内容，新内容不会主动刷新过来。 　　访问： http://localhost:9090/name 结果如下： 　　重启 Config Client 以后，访问： http://localhost:9090/name 结果如下： 　　但是，总不能每次修改了配置后重启服务吧。如果是那样的话，还是不要用它为好，直接用本地配置文件岂不更快。 　　它提供了一个刷新机制，但是需要我们主动触发。那就是 @RefreshScope 注解并结合 Actuator ，注意要引入 spring-boot-starter-actuator 。 　　 添加依赖 　　 　　Config Client 添加 spring-boot-starter-actuator 依赖。 <!

step: 安装 jenkins通用插件：Generic Webhook Trigger job 配置webhook token git仓库配置webhook 来源： oschina 链接： https://my.oschina.net/attacker/blog/4456540

背景说明 我们在业务上容器的过程中遇到了如下问题： 以deployment部署的应用pod，由于id经常变更，服务重启，监控变得难以维护。这里只是以监控为切入点，事实上，还有诸多应用需要与id强绑定。 statefulset可以解决上面的问题，但是引入一个新的问题就是statefulset本身为了维护有状态的应用，所有的应用Pod启动是有严格的先后顺序，也就是串行启动，对于大规模的应用pod来讲，启动消耗时间太长，这是无法忍受的。 为解决以上问题，我们在容器平台当中引入了openkruise。 openkruise简介 项目地址： https://github.com/openkruise/kruise 详细的说明可以参考这篇文章： 《OpenKruise - 云原生应用自动化引擎正式开源》 从当前github上的文档来看，目前OpenKruise支持五种改进的控制器： CloneSet: CloneSet is a workload that mainly focuses on managing stateless applications. It provides full features for more efficient, deterministic and controlled deployment, such as inplace update, specified

作者：CODING - 王炜 1. 背景 如果对 Kubernetes 集群安全特别关注，那么我们可能想要实现这些需求： 如何实现 Kubernetes 集群的两步验证，除了集群凭据，还需要提供一次性的 Token 校验？ 如何验证部署的镜像是否安全合规，使得仅允许部署公司内部镜像仓库的 Docker 镜像？ 如何实现对每一个 Deployment 动态注入 sidecar ，满足特定安全或业务需求？ 如何实现集群级的 imagePullSecrets ，当创建新的命名空间的时候，自动将 imagePullSecrets 注入到新的命名空间？ 本文以实现 Kubernetes 两步验证为例，利用 Kubernetes Admission 动态准入控制，同时借助 Serverless 实现一个 两步验证 的 Demo，使读者对 动态准入控制 和 Serverless 有较深入的了解。 1.2 实现效果 Token 两步验证失败，不允许部署 Token 两步验证成功，允许部署 2. 什么是 Admission Admission 是在用户执行 kubectl 通过认证之后，在将资源持久化到 ETCD 之前的步骤，Kubernetes 为了将这部分逻辑解耦，通过调用 Webhook 的方式来实现用户自定义业务逻辑的补充。而以上过程，都是在用户执行 kuberctl 并等待 API