最近在对zabbix依赖的接口主动探测脚本做配置化改造，脚本里面用到了importlib提供的动态import功能，由于这一次一时性起全程vim操作没有用pycharm，vim一时爽，一直用一直爽，雾~ 等会我会说到不用pycharm导致的问题。 下面我用一个demo来复现一下问题，也便于大家理解，以下是目录结构和代码内容： 你可以按照上面的目录结构和代码内容组织好，然后用python2运行一下，大致会报下面的错误， 总之会直接报没有叫cc_test的模块的错误，这样子就很迷惑了，你左看右看demo目录下都有一个叫…
今天进入Wsl里面的Ubuntu时提示rpc服务器不可用错误，英文应该是rpc server is unavailable。 一番折腾发现是前几天因为配置Win10的hosts绑定时由于在ip后煞笔的加了端口号，导致hosts绑定怎么弄都不生效，然后听信网上的说法用命令行修改注册表关闭了Win10的DNS客户端，如果是这样的话解决方法很简单，重新执行下面的命令，把dns客户端设置为自动启动，然后重启电脑即可，之前用命令行修改注册表关的dns客户端的不要幻想用service.msc去启动，你会发现都是灰色的不给你启动…
首先打开你的项目下的setting.py文件，然后找到 INSTALLED_APPS这个列表变量，然后在里面加入如下两项： 然后在settings.py中的任意位置加入一个 SITE_ID = 1 的变量，然后在你的项目根目录运行下面的命令进行数据库同步， 然后我们来到项目的urls.py文件中，先import一个用于sitemap的django类和你的假定表示文章的数据库模型Post， 紧接着，我们在urls.py中新建一个字典，再定义一个path()，如下： 然后我们还要到项目的models.py中…
背景 最近在全面接手估计有1k+的生产日志的运维工作，每天面临着大量的投诉，大部分的诉求都是日志突然没了，为了对生产故障进行排查要紧急查看日志，由于应用系统数量和种类繁多，以及所有日志系统的网络架构的复杂性导致出现这种问题有时并不能快速解决，与其每天被动的的接受开发的投诉，还不如主动的对这1K+应用产生的Elasticsearch索引进行运维治理。 其实应用突然没日志无外乎下面几种： k8s pod里面的log挂载点发生了变化 log4j里面的日志路径发生了变化 应用上云后log4j里面的路径没有进行同步变更 还有…
Linux机器: 这里有两个地方需要注意，否者会有严重问题： 1、要先到这里把第一种模式的restart脚本放到saltmaster上，然后在下发完filebeat配置之后把restart脚本也下发一下再执行重启filebeat命令，否者salt会卡住， 这种场景主要是因为某些情况下为了排障生产的filebeat启用了这里提到的中的第二种简单排错模式，这种模式会导致salt命令卡住 2. salt的重启filebeat命令一定要用"cd /data/filebeat/ && sh rest…
1. 用于saltstack自动化部署模式：所有输出全部定向到/dev/null，可以实现在自动化下发配置的时候salt命令全程不卡住 2、简单排错模式：把debug输出重定向追加到文件，适用于判断与ES VIP后端节点的通信情况判断，以及简单的判断filebeat是否启动harvester组件采集某个路径下的日志 3、全部 debug selector都开启模式：适用于分析filebeat全部采集链路，非特殊情况慎用，用完及时关闭，否者短时间内日志暴涨几十G
背景 完整的报错内容如下： filebeat failed to publish events 413 request entity too large 遇到此种报错将会导致es中没有数据 解决方法 找到filebeat的主配置filebeat.yml，在output中加入 bulk_max_size: 20，这个值默认是50，我们要改小一点，改成10或者20都行，由于yaml这种格式极易出错引起不适，我把相关的部分摘录如下：
子舒博客