“XXX，帮我在10.10.10.10上加一条cron”，

“XXX，再帮我在10.10.10.11上加一台cron”，

“XXX，10.10.10.10上的cron怎么没有执行啊，怎么回事”

……

以上对话是在日常工作中，是运维同学经常要面对来自研发同学的灵魂拷问，各个研发同学的很多条定时任务，每次都找运维同学的话，恐怕运维同学每天处理cron的时间就占据大部分了。

在业务优先的前提下，运维人员要面对的不仅仅是研发的巨大压力，cron添加，cron修改，cron搜索，cron日志，cron告警……，各个步骤都不能出错，一旦出错，就可能引发线上事故了，但是这种海量定时任务的管理，想每条都精确无误，无疑是个巨大的挑战。

        如果上述问题迟迟得不到解决的话，长此以往必会引发更大的问题，也会给运维工作带来更大的挑战。如何解决这个问题？定时任务无非就是定时加任务，定时就是crontab的时间格式，为防止格式出现问题，必须要加入格式验证，python拥有丰富的第三方库，我们这里选用croniter模块来进行定时时间格式的验证，再从任务二字，从这里可以联想到我们运维管理平台已有的基于SaltStack二次开发的作业平台，我们可以再基于这个作业平台，开发出满足业务需求的crontab管理的工具，还避免了重复造轮子，造成资源的浪费。

Crontab集中化管理，要解决的问题主要有四个：

l   现有的定时任务如何接入

l   定时任务的管理，增删改查

l   定时任务的日志查询

l   定时任务执行失败告警

针对以上四个难点，我们一一来介绍一下。

        首先是第一个问题，现有的定时任务如何接入？定时任务接入的前提肯定是不能影响已有的定时任务，Python有个crontab的模块，轻便易用，使用这个模块可以方便的读取已有的crontab，并给已有的定时任务增加日志重定向，重定向到制定目录下，方便后续的日志收集。在使用这个模块的时候，我们顺便加上一个备份的动作，这样即使接入出现问题，也不会造成什么影响。

        第二个问题，crontab的增删改查。这里用的也还是python的crontab模块，通过该模块，计算得到增删改后的新的定时任务，然后再通过二次开发后的SaltStack调度，将增删改后的新定时任务分发到指定的机器上，完成这一系列的操作。

        但是这里存在一个问题，假设我们在cron管理平台上操作A机器上的B定时任务，而恰巧同时又有另一个人直接在A机器上直接操作B 定时任务，这样势必会引发冲突，导致不可预知的后果，那么如何解决这个问题？这里我们加入了一层验证来避免这个问题，每次通过平台操作的增删改，都会先从数据库拉去一份最新的定时任务的记录，然后分发到机器上后，与机器本身实际的定时任务对比，如果对比出现异常（有不同的地方），则在平台上抛出异常，此次的增删改被记录为失败，必要要先手动解决异常，才能继续操作，这样也能避免运维与研发同学直接从机器上操作crontab，而全部在平台上操作crontab。

        第三个问题，日志查询。这里我们接入了已有的ELK日志收集系统，ELK是一个日志收集分析的平台，能收集海量的日志，并根据字段来切割，通过ELK收集crontab的日志并储存到Elasticsearch中，Elasticsearch是一种实时的分布式的海量数据搜索与分析引擎，在平台上查询crontab的日志时，是直接从Elasticsearch中查询的，保证了日志查询的速度。

        第四个问题，crontab执行失败告警。定时任务执行失败会在日志中留下” retcode_error”的标记，通过脚本去Elasticsearch中的crontab的日志中搜寻这个标记，一旦找到这个标记，则发出告警给对应cron的负责人。这样也就完成了crontab的告警，让负责人随时了解crontab的执行情况。

针对上面四个问题，可以用如下一张图概括下来。

        关于crontab执行失败的告警，每条定时任务都对应一个管理员，管理员身份可以认领，也可以被指派，一旦定时任务执行失败，我们采用邮件通知的方式，将邮件发送到该条定时任务对应的管理员，并在邮件中给出具体的报错原因。