предисловие

Прежде всего, давайте представим предысторию: продукты нашей компании будут развернуты непосредственно в Стороне А, потому что Стороны А много, и они содержат более персонализированные потребности, поэтому каждую Сторону А можно понимать как git-ветвь нашего продукта. Поскольку машинная среда Стороны А и сетевая среда различаются, часто возникают некоторые проблемы во время выполнения, поэтому я разработал эту простую интеллектуальную систему мониторинга для отслеживания условий интерфейса каждой Стороны А в режиме реального времени.

Область применения

Область применения, полученная из этого пакета, следующая:

Проект с несколькими контейнерами под управлением Docker, и оно недоступно для времениинтерфейсОбнаружение работоспособности, решение может быть реализовано для определения состояния нескольких рабочих точек.
У компании есть несколько операционных сред для одного и того же набора кода, и ей необходимо отслеживать состояние каждой среды.
После того, как проект будет разветвлен, он будет развернут в каждой Стороне А (включая персонализированные требования) — это мы.

визуализация

Подведите мышку к определенному интерфейсу, вы увидите время создания узла и параметры интерфейса в это время. [Здесь показаны только узлы изменений]

Где 200 является эталон JSON кода состояния, обычно используемый в нашем проекте. Параметр не может разрешать код состояния (например, ошибка сервера 500), не отображается.

Щелкните узел, чтобы снова смоделировать вторичный узел, отобразив параметры в браузере.

Дважды щелкните узел, чтобы скопировать выходные параметры узла.

предметный анализ

Поскольку в нашем продукте завершено разделение внешнего и внутреннего интерфейса (представленное в предыдущих статьях), мы сосредоточимся на мониторинге интерфейса.

Мой план:

Через регулярные промежутки времени, например каждые 3 минуты, активно получайте (или публикуйте) http-интерфейс (включая информацию о пользователе) для получения параметров интерфейса.
Если экспортная галевка одинаково, он отмечен, если экспорт интерфейса одинаковый.
Передняя часть показывает, что каждый интерфейс соответствует всем изменениям в каждом проекте и упорядочивает разницу узлов.
Здесь мы отслеживаем и не заботимся о содержимом выходных параметров интерфейса, и не проверяем допустимость выходных параметров узла, потому что мы сталкиваемся со всеми интерфейсами.

Анализ интерфейса

Здесь, из-за различных интерфейсов каждой компании, методы шифрования для входа и выхода недоступны, и аутентификация личности также отличается.Мы напишем метод для реализации шифрования и дешифрования независимо.Поэтому я ввожу только незашифрованные и расшифрованные параметры; Что касается справки, то в качестве примера используется {"code":"200","data":null,"message"::"success"}, и я объясню эту статью простым токеном для аутентификации .

Интерфейс для получения списка новостей:

http://*.com/v1/news?token=2c789e34dc81d79feba6a005ad63902b

Расшифрованные выбросы:

{"code":"200","data":[{"id":"1","title":"这是一条假新闻","url":"http://"},{"id":"2","title":"这是一条假新闻","url":"http://"}],"message"::"success"}

Из интерфейса

ПОЛУЧИТЬ метод
Входной токен = 2c789e34dc81d79feba6a005ad63902b
Выходной параметр: {"code":"200","data":[],"message"::"success"}
Среди них *.com может быть разным для каждой среды, например адреса 10.0.0.1 и 10.0.0.2 под контейнером
Токен отличается в каждой Стороне А.

При добавлении интерфейса получения новостей:

Относительный URL:

v1/news

Тип запроса:

get

основной корпус:

token={token}

хрон выражение:

0 0/3 * * * ?（每隔3分钟执行一次）

При добавлении среды A:

хост (обязательно)

http://a.com

параметры (список)

token 2c789e34dc81d79feba6a005ad63902b

При добавлении среды B:

хост (обязательно)

http://b.com

параметры (список)

token 4297f44b13955235245b2497399d7a93

Связывание интерфейсов и сред

Интерфейс может связывать несколько сред
Среда может связывать несколько интерфейсов
В базу данных записывается только односторонняя привязка, которая логически является двусторонней.

Например, если среды A и B привязаны к интерфейсу получения новостей, раунд запросов к интерфейсу выполняется каждые 3 минуты.

А:

Хост среды + относительный URL =

http://a.com/v1/news

Тип запроса:

get

основной корпус:

token=2c789e34dc81d79feba6a005ad63902b

Б:

Хост среды B + относительный URL =

http://b.com/v1/news

Тип запроса:

get

основной корпус:

token=4297f44b13955235245b2497399d7a93

Нашу структуру не волнует количество параметров, она только проходит через интерфейс с заполнителями и заменяет поля в заполнителях переменными в списке параметров в среде. Например, тело имеет вид token=2c789e34dc81d79feba6a005ad63902b&type=1&mobile=2.

При добавлении интерфейса тело заполняется:

token={token}&type={type}&mobile={mobile} 其中占位符可以随便起名字

Параметры (список) при настройке среды следующие:

k	v
token	2c789e34dc81d79feba6a005ad63902b
type	1
mobile	2

Соответствие между параметрами и заполнителями не связано с другими переменными URL.

Фронтальный дисплей

Горизонтальная ось представляет время. Каждый узел, который изменяется, является изменением выходного параметра. Узел содержит входные параметры и выходные параметры в это время. Нажмите левую кнопку, чтобы снова имитировать запрос, чтобы получить расшифрованные выходные параметры; дважды щелкните, чтобы скопировать выходные параметры.

Для разных кодов статуса у нас есть разные цвета. Вы можете выбрать подходящий цвет в соответствии с кодом ошибки в вашем продукте. Чем выше уровень ошибок, чем более заметной цвет.

Щелкните правой кнопкой мыши узел, чтобы просмотреть исторические решения и добавить новые решения, например решение этой ошибки с кодом 999, является разрешением службы перезапуска, затем введите службу перезапуска, а затем добавьте ее. Следующий другие люди могут увидеть, как решить эту проблему, отдавать приоритет делать.

разные презентации

Он содержит две разные широты.Вы можете напрямую щелкнуть, чтобы войти, чтобы просмотреть статус мониторинга всех интерфейсов в среде A, или просмотреть статус мониторинга всех сред в интерфейсе 1.

или:

Интерфейс редактирования окружения:

Интерфейс редактирования задачи:

Основные технологии

Поскольку это периодический мониторинг, естественно использовать выражения cron.Мы java-проект, поэтому мы используем кварцевый фреймворк.

код кварцевого сердечника

public class QuartzSchedule {

    private static SchedulerFactory sf = new StdSchedulerFactory();
    private static Scheduler sched;
    final static String groupName = "task";


    public static void init() throws IOException, SchedulerException {
        //查询所有需要执行的任务和项目列表
        // 使用类加载器，加载mybatis的配置文件
        InputStream inputStream = Resources.getResourceAsStream("mybatis-config.xml");
        // 构造sqlSession工厂
        SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);
        SqlSession sqlSession = sqlSessionFactory.openSession();
        MprojectTaskDao mprojectTaskDao = sqlSession.getMapper(MprojectTaskDao.class);
        sched = sf.getScheduler();
        //只查询所有在m_project_include表里面的任务
        List<MprojectTask> mprojectTaskList = mprojectTaskDao.findList();
        for (MprojectTask mprojectTask : mprojectTaskList) {
            startJob(mprojectTask);
        }
    }

    public static void stopTask(MprojectTask mprojectTask) {
        TriggerKey triggerKey = TriggerKey.triggerKey(mprojectTask.getId(), groupName);
        try {
            sched.pauseTrigger(triggerKey);// 停止触发器
            sched.unscheduleJob(triggerKey);// 移除触发器
            sched.deleteJob(JobKey.jobKey(mprojectTask.getId(), groupName));// 删除任务
        } catch (Exception e) {
            e.printStackTrace();
        }
    }

    /*
     停止和暂停均可使用
     */
    public static void startTask(MprojectTask mprojectTask) {
        //无论是否关闭，先关闭任务再开启。
        stopTask(mprojectTask);
        startJob(mprojectTask);
    }


    private static void startJob(MprojectTask mprojectTask) {
        try {
            JobDetail jobDetail = JobBuilder.newJob(TaskQuzrtzJob.class).withIdentity(mprojectTask.getId(), groupName).build();
            // 触发器
            TriggerBuilder<Trigger> triggerBuilder = TriggerBuilder.newTrigger();
            // 触发器名,触发器组
            triggerBuilder.withIdentity(mprojectTask.getId(), groupName);
            triggerBuilder.startNow();
            // 触发器时间设定
            triggerBuilder.withSchedule(CronScheduleBuilder.cronSchedule(mprojectTask.getCron()));
            // 创建Trigger对象
            CronTrigger trigger = (CronTrigger) triggerBuilder.build();
            // 调度容器设置JobDetail和Trigger
            sched.scheduleJob(jobDetail, trigger);
            // 启动
            if (!sched.isShutdown()) {
                sched.start();
            }
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
}

основной код работы

public class TaskQuzrtzJob implements Job {

    public TaskQuzrtzJob() throws IOException {
    }

    //JobExecutionContext context传递参数值
    public void execute(JobExecutionContext context) {
        //通过context得到该任务的所有环境
        //遍历所有环境
            //拼凑出请求地址
            //使用封装的框架加密发送请求
            //得出出参解密后的结果
            //与上次进行比对，不相同则标记，入节点表
            //入记录表
    }
}

Объем данных

Поскольку каждый интерфейс (задача), который мы отслеживаем, имеет несколько сред, предполагая 100 интерфейсов и 100 сред и отслеживая каждые 3 минуты, количество ежедневных записей составляет

100 * 100 * 20 * 24 = 4800 000 записей, эта запись довольно удивительна, поэтому мы разделили две таблицы, одна таблица записывает только записи, а другая таблица записывает изменения.При отображении узлов запрашивается только таблица изменений.Решить производительность проблемы.

внешний интерфейс

Css-интерфейс для рисования круга и цвета

round {
    border-radius: 50%;
    text-align: center;
    width: 25px;
    height: 25px;
    line-height: 25px;
}

.on {
    border: 1px solid #7CBA23;
}

Линии рисуют линии с помощью линии

line {
    border-bottom: 1px solid gainsboro;
    height: 2px;
    width: 20px;
}

Общий угловой список JS рендеринг

база данных

Для подключения используем базу данных mysql, фреймворк mybatis.

Ненормальное напоминание

Мы свяжем каждый интерфейс с кодом состояния. При обнаружении отклонения от нормы отправьте электронное письмо. После того, как тестер проверит проблему, она будет возвращена в разработку. После того, как разработка будет решена, решение будет введено для следующего запрос.

Суммировать

Эта платформа была опробована в течение одного месяца и в целом соответствовала нашим потребностям в прошлом, мы запускали тестовый сценарий, часто не можем отслеживать состояние здоровья сервера в режиме реального времени, теперь любая проблема с окружающей средой, мы в режиме реального времени, и можем подсчитайте определенную среду, с какого времени до какого времени интерфейс ненормальный.

У этой платформы мало функций, но она значительно упрощает нашу оценку экологической устойчивости, а также собирает большой объем данных для последующего статистического анализа. Во-вторых, схема немного видоизменена и может использоваться в различных сценариях мониторинга.

Перспектива

В будущем я включу некоторый интеллектуальный анализ, например, следующее содержание напоминания по электронной почте:

(Интеллектуальный мониторинг) Обнаружено, что интерфейс [Получить список новостей] в «Личной среде клиента А» ненормальный, а код исключения — 102; Выходной параметр: {"data":null,"message":"success","state":102}

Исторические решения:

Перейдите на сторону управления, чтобы перезапустить контейнер.
В таблице xx есть аномальные грязные данные. Согласно исторической статистике, вероятность варианта 1 составляет 80%, а вероятность варианта 2 – 10%.

Интерфейс среды был нормальным 5 минут назад, а выходной параметр — {"data":null,"message":"No data","state":200}

Были обнаружены две другие аномалии среды, а именно среды XXX и YYY. Однако нештатное состояние не похоже на школьное, поэтому причина бага интерфейса war package исключена.

Поскольку другие интерфейсы «XXX Environment» ненормальны для определенного мониторинга в течение 5 минут, (интеллектуальный мониторинг) самостоятельно вызвал модуль самовосстановления контейнера, и служба была восстановлена.На этот раз для сбора данных требуется 5 минут и 100 минут для анализа проблемы. миллисекунд, самовосстановление занимает 60 секунд, время прерывания обслуживания в этой среде составляет 6 минут, общее время прерывания обслуживания в этом месяце составляет 15 минут, а высокая доступность составляет 98,33%.

over