Sorry, you have been blocked
This website is using a security service to protect itself from online attacks. The action you just performed triggered the security solution. There are several actions that could trigger this block including submitting a certain word or phrase, a SQL command or malformed data.
What can I do to resolve this?
You can email the site owner to let them know you were blocked. Please include what you were doing when this page came up and the Cloudflare Ray ID found at the bottom of this page.
Cloudflare Ray ID: 7a286c101cdb2301 • Your IP: Click to reveal 88.135.219.175 • Performance & security by Cloudflare
Сфера EDI (
Метод для получения списка взаимосвязей с партнерами по обмену.
https://edi-ws.esphere.ru/relationships
Аргументы вызова:
Name;
Password.
Как пытаюсь подключиться:
Определение = Новый WSОпределения("https://edi-ws.esphere.ru/edi.wsdl". Новый ЗащищенноеСоединениеOpenSSL);
Прокси = Новый WSПрокси(Определение, "http://edi-express.esphere.ru/","EdiExpressTransportService", "RelationshipsEndpointPort");
Фабрика = Прокси.ФабрикаXDTO;
ОбъектXDTO = Фабрика.Создать(Фабрика.Тип("http://edi-express.esphere.ru/", "RelationsInput")); //relationships я не нашёл
ОбъектXDTO.Name = "ххх";
ОбъектXDTO.Password = "ууу";
РезультатRelationships = Прокси.RelationsInput("ххх", "ууу");
Ошибка: РезультатRelationships = Прокси.RelationsInput("ххх", "ууу"). Метод объекта не обнаружен (RelationsInput)
у меня работает так:
Функция ПолучитьВзаимосвязи()
WSОпределение = Новый WSОпределения("https://edi-ws.esphere.ru/edi.wsdl");
Прокси = Новый WSПрокси(WSОпределение, "http://edi-express.esphere.ru/", "EdiExpressTransportService", "RelationshipsEndpointPort");
RelationsInput = Прокси.ФабрикаXDTO.Создать(ТипRelationsInput);
RelationsInput.Name = "login";
RelationsInput.Password = "password";
Возврат Прокси.process(RelationsInput);
КонецФункции
У меня вот это получилось))
WSПараметр.Name = ЛогинСфераEDI;
WSПараметр.Password = ПарольСфераEDI;
Логи IIS — очистка
Веб-сервер IIS в процессе своей работы генерирует достаточно большие объемы log-файлов. Все бы ничего, но по умолчанию логи IIS располагаются на системном диске , которому обычно не предоставляют большой объем. Хорошо, если у вас виртуальная машина и вы можете просто не обращать внимание на нехватку диска C:\, увеличивая его объем по необходимости, благо функционал виртуальных машин Hyper-V второго поколения позволяет увеличивать размер даже системного диска без выключения сервера, прямо налету. А если у вас такой возможности нет? В таком случае разрастание логов может стать для вас серьезной проблемой.
В статье я расскажу как обращаться с log-файлами IIS и автоматизировать процесс удаления.
Если вам интересна тематика Windows Server, рекомендую обратиться к тегу Windows Server на моем блоге.
Логи IIS
По умолчанию логи IIS располагаются в каталоге %SystemDrive%\inetpub\logs\LogFiles. Сигналом для их очистки может служить истощающееся быстрыми темпами свободное место системного диска. В этом случае системные администраторы начинают искать что же занимает столько места и благополучно пропускают папку inetpub, поскольку по умолчанию она практически ничего не весит:
Но почему? Дело в том, что изначально вы не имеете разрешений на вложенные папки, следовательно не можете увидеть их реальный объем:
Попробуйте зайти в каждую подпапку каталога %SystemDrive%\inetpub\logs\LogFiles, соглашаясь с назначением необходимых разрешений и в итоге увидите, что реальный объем папок не так уж и мал:
Разумеется у меня приведены в пример скриншоты с тестового сервера. Объем логов серверов в продакшене может достигать десятков и сотен гигабайт совершенно спокойно.
Итак, проблема найдена, пора заняться очисткой. Теоретически её можно проводить и вручную, но в этом нет никакого смысла и проще все сделать скриптами, в некоторых случаях достаточно даже одной команды PowerShell. В одной из статей по Exchange 2013 (см. Очистка папки Logging Exchange 2013) я уже рассматривал вопрос автоматизации процесса очистки логов, но не помешает напомнить о нем и в этой статье.
Команда для очистки log-файлов в нашем случае будет выглядеть следующим образом:
Как мы Elasticsearch в порядок приводили: разделение данных, очистка, бэкапы
Эта статья — практическая история о том, как мы столкнулись с проблемой разделения логов, хранимых в Elasticsearch, из-за которой пришлось поменять подход к бэкапам и управлению индексами.
Всё началось вскоре после того, как было поднято production-окружение. У нас был «боевой» кластер Kubernetes, все логи из которого собирал fluentd и направлял их напрямую в индексы logstash-yyy.mm.dd …
Однако появился запрос хранить некоторые логи приложений для поиска до 90 дней. На тот момент мы не могли себе этого позволить: хранение текущих индексов за такой период превысило бы все разумные меры. Поэтому было принято решение создать отдельный индекс-паттерн для таких приложений и настроить на него отдельный retention.
Разделение логов
Чтобы выполнить такую задачу и отделить «нужные» логи от «ненужных», мы воспользовались параметром match у fluentd и создали еще одну секцию в output.conf для поиска совпадений по нужным сервисам в пространстве имён production согласно тегированию, указанному для input-плагина (а также изменив @id и logstash_prefix , чтобы направить запись в разные места).
Фрагменты получившегося output.conf :
Итог — у нас два вида индексов ( log-prod-yyyy.mm.dd и logstash-yyyy.mm.dd ):
Очистка индексов
На тот момент в кластере уже был настроен curator, который очищал индексы старше 14 дней. Он описывался как объект CronJob для разворачивания прямо в кластер Kubernetes.
Иллюстрация в action_file.yml :
Однако мы решили, что вариант с куратором избыточен (запускается как отдельное ПО, требует отдельной настройки и запуска по крону) — ведь можно переделать очистку с помощью index lifecycle policy.
В Elasticsearch с версии 6.6 (вышла в январе 2019 года) появилась возможность прикрепления к index template политики, которая будет отслеживать время хранения для индекса. Политики можно использовать не только для управления очисткой, но и других задач, которые позволят упростить взаимодействие с индексами (например, выравнивание индексов по размеру, а не по дням).
Для этого требовалось лишь создать две политики такого вида:
… и прикрепить их к требуемым index templates:
Теперь кластер Elasticsearch будет самостоятельно управлять хранением данных. Это означает, что все индексы, которые попадут под шаблон в index_patterns , указанный выше, будут очищаться после заданного в политике количества дней.
Но тут мы сталкиваемся с другой проблемой…
Реиндексирование внутри кластера и из удаленных кластеров
Созданные нами политики, шаблоны и те изменения, что были применены во fluentd, будут иметь эффект только для новых создаваемых индексов. Чтобы привести в порядок то, что уже имеем, придется запустить процесс переиндексации, обратившись к Reindex API.
Требуется выделить «нужные» логи из уже закрытых индексов и реиндексировать их самих, чтобы были применены политики.
Для этого достаточно двух простых запросов:
Теперь старые индексы можно удалить!
Однако есть и другие трудности. Как уже известно, ранее был настроен curator, который чистил кластер с retention в 14 дней. Таким образом, для актуальных для нас сервисов потребуется восстановить данные и из того, что уже было когда-то удалено. Здесь помогут бэкапы.
В простейшем случае, что применимо и к нашему, бэкапы делаются посредством вызова elasticdump для всех индексов разом:
Развернуть все, что было от запуска production, не представлялось возможным, т.к. в кластере банально не было столько места. К тому же, доступ к логам из бэкапа требовался уже сейчас.
Решение — развернуть временный кластер, в который восстанавливается бэкап, откуда уже и достаются нужные нам логи (способом, аналогичным уже описанному). А параллельно мы начали думать, как сделать снятие бэкапов более удобным способом — подробнее об этом см. ниже.
Итак, следующие шаги (по временному кластеру):
- Установить еще один Elasticsearch на отдельный сервер с достаточно большим диском.
- Развернуть бэкап из имеющегося у нас dump-файла:
Параметры size и slice используются для ускорения процесса реиндексации:
- size — для увеличения количества документов для индексации, передаваемых в пакете;
- slice — для деления этой задачи на 6 подзадач, которые будут параллельно заниматься реиндексированием. (Параметр не работает в реиндексации из удаленных кластеров).
Когда все нужные логи оказались в одном месте полностью разделенными так, как требовалось, временный кластер можно удалять:
Бэкапы Elasticsearch
Самое время вернуться к бэкапам: запуск elasticdump на все индексы — далеко не самое оптимальное решение. Хотя бы по той причине, что восстановление может занимать неприлично много времени, а бывают случаи, когда важен каждый час.
Такую задачу можно «отдать» самому Elasticsearch — Snapshot Repository на базе S3. И вот основные причины, по которым мы сами выбрали такой подход:
- Удобство создания и восстановления из таких бэкапов, поскольку используется родной синтаксис запросов к Elasticsearch.
- Снапшоты накатываются инкрементально, т.е. добавляя новые данные к уже имеющимся.
- Возможность восстановить из снапшота любой индекс и даже восстановить глобальное состояние кластера.
- S3 кажется более надежным местом для хранения бэкапов, чем просто файл (в том числе и по той причине, что обычно мы используем S3 в режимах HA).
- Переносимость S3: мы не привязаны к конкретным провайдерам и можем развернуть S3 на новом месте самостоятельно.
-
Устанавливаем плагин для S3 на все узлы:
… и параллельно добавляем S3 в whitelist в elasticsearch.yml :
В данном случае для создания снапшота хватит примеров из документации, где имя снапшота будет в формате: snapshot-2018.05.11 ,— т.е.:
Статус восстановления же можно проверять из самого кластера: в начале восстановления кластер перейдет в статус red , т.к. будут восстанавливаться primal-шарды ваших индексов. Как только процесс будет завершен, индексы и кластер перейдут в статус yellow — до того момента, как будет создано указанное количество реплик.
Также отслеживать статус можно с помощью wait_for_completion=true , указанном прямо в строке запроса.
Результат — получаем точную копию индекса из сделанного снапшота:
Итоги и недостатки
Оптимальными для нас решениям в кластере Elasticsearch оказались:
- Настройка output-плагина в fluentd, с которой можно разделять логи прямо на выходе из кластера.
- Политика index lifecycle, позволяющая не заботиться о проблемах с местом, занятым индексами.
- Новый вид бэкапов через snapshot repository (вместо бэкапа целого кластера), с которым появилась возможность восстанавливать отдельные индексы из S3, что стало гораздо удобнее.
Несмотря на то, что мы «передали» выполнение бэкапов самому Elasticsearch, запуск снятия снапшота и наблюдение за его выполнением всё еще остается нашей задачей: обращение к API, отслеживание статусов (через wait_for_completion ) и по статусу мы будем производить сами с помощью скриптов. При всей удобности backup repository есть у него и другая проблема: слишком мало плагинов. Например, нет возможности работать через WebDAV, если вместо S3 понадобится что-то совсем простое, но такое же мобильное.
В целом, такая обособленность системы плохо ложится на использование централизованного подхода к бэкапам и мы пока не нашли (среди Open Source-инструментов) универсальное средство, которое бы это позволило.