Журнал LinuxFormat - перейти на главную

LXF146:Sysadmin

Материал из Linuxformat
Перейти к: навигация, поиск

Содержание

По рецептам доктора Брауна

Эзотерическое системное администрирование из причудливых заворотов кишок серверной


За исследования!

Splunk Тонете в файлах журнала? Ответом может стать «поисковая система оперативной разведки»...

Занятые серверы Linux генерируют бездну машинных данных, от журналов web-доступа Apache до предупреждений sshd об отказах в попытке доступа.

Для их исследования существуют несколько классических утилит. Скажем, Logwatch – прекрасная программа для создания сводок файлов журнала, и имеется куча программ, помогающих понять, хорошо ли функционирует ваш сайт (например, http://www.sawmill.co.uk).

Splunk (http://www.splunk.com) немного другой. Он предпринимает более интерактивный подход к добыче данных с вашей машины – возможно, чтобы глубже забуриться в поисках проблемы эксплуатации либо рассмотреть долгосрочные тенденции в работе машины.


Splunk работает как демон. Как и Beagle, он обшаривает машинные данные и индексирует их. Но Beagle ищет вашу персональную информацию, а Splunk – информацию о системе. Интерфейс его основан на web-браузере.

На настройку источников данных для Splunk требуется время. Он умеет индексировать вывод системного журнала, журналы событий окон, файлы настройки (и вообще любые указанные файлы), журналы Apache и WebSphere, и многое другое.

Приведенный ниже снимок экрана показывает простой поиск строки «failed» в системном журнале. Оказывается, имел место огромный всплеск около 8 утра 14 апреля. Копнув глубже, мы видим, что более 99,9 % этого исходит от программы под названием ntfs-3g. Фильтрация по времени генерации, по хосту, откуда это пришло, и по файлу журнала очень проста. Можно просматривать индивидуальные сообщения и даже перейти прямо на файл журнала, откуда идут ошибки.


XML для администраторов

XML Вы испытывали чувство, что этот язык ставит вас в тупик? Добрый Доктор преподает простое введение, исцеляя ваш истерзанный разум.

Несколько лет назад, когда Novell перешел с NetWare на Linux, я проводил множество тренингов для их консультантов. Некоторые из них считали переход шагом в неверном направлении, хотя бы в техническом отношении, и не стеснялись твердить мне это.

Любимой мишенью их критики было изобилие форматов файлов системных настроек в Linux. «Не разумнее ли, – спрашивали они, – везде использовать XML?»

Я и тогда не соглашался с этой идеей, и теперь не согласен. С тем же успехом можно предложить записывать все файлы как ASCII-строки, чтобы они имели общую структуру. Хотя, конечно, XML открывает новое измерение в разнообразии мини-языков.

Лично мне XML не нравится. Он напоминает мне куски сырого сала, вывешиваемые зимой для синиц – хорошо для своих целей, но для людей несъедобно. Он засоряет страницу, тяжело читается и требует много лишнего места. И так уж вышло, что XML все-таки не используется в базовых файлах настройки Linux, типа /etc/passwd, /etc/fstab и /etc/hosts; и даже файл syslog-ng.conf устоял перед наваждением XML.

Но в других местах вы встретите множество XML под капотом. Например, документ OpenOffice.org – это на самом деле zip-архив XML-файлов с именами типа content.xml и style.xml. (Просто разархивируйте любой документ .odt, и сами убедитесь.)

Все файлы из каталога ~/.gconf, где хранятся настройки рабочего стола Gnome, имеют формат XML. На моей стандартной установке Fedora 14 в /etc их 212, что дает 191,000 строк XML – в основном в /etc/gconf. Библиотека виртуализации libvirt использует XML для определения характеристик виртуальной машины и виртуальной сети.

Поэтому в данном номере мы бегло рассмотрим формальный мир XML.


Рабочий пример

Текст для сегодняшнего урока взят из примера определения машины в libvirt. Этот XML-файл описывает аппаратную конфигурацию виртуальной машины:

<?xml version=”1.0” encoding=”utf-8” ?>
<domain type='kvm'>
<name>serverq</name>
<uuid>3cce3bbc-5d3c-ee98-e4d5-4cefb0f9bdf5</uuid>
<memory>262144</memory>
<currentMemory>262144</currentMemory>
<vcpu>1</vcpu>
<os>
<type arch='x86_64' machine='pc-0.12'>hvm</type>
<boot dev='hd'/>
</os>
<features>
<acpi/>
</features>
<clock offset='utc'/>
<on_poweroff>destroy</on_poweroff>
<on_reboot>restart</on_reboot>
<on_crash>destroy</on_crash>
<devices>
<emulator>/usr/bin/kvm</emulator>
<disk type='file' device='disk'>
<source file='/home/chris/q-vm/tmp_Hy.qcow2'/>
<target dev='hda' bus='ide'/>
</disk>
<interface type='network'>
<mac address='52:54:00:2d:5d:4d'/>
<source network='default'/>
<model type='virtio'/>
</interface>
<input type='mouse' bus='ps2'/>
<graphics type='vnc' port='-1' autoport='yes' listen='127.0.0.1'/>
<video>
<model type='cirrus' vram='9216' heads='1'/>
</video>
</devices>
</domain>

На рисунке вверху я детально разобрал фрагмент этого файла. Вкратце, документ XML состоит из элементов с начальным тэгом и конечным тэгом. Начальный тэг может содержать атрибуты (простые пары имя/значение). Между начальным тэгом и конечным тэгом находится содержимое элемента. Это может быть простой текст или (что более важно) другой элемент XML, что придает XML иерархическую структуру.

Давайте добавим терминологии. В моем файле примера первая строка технически называется прологом. В ней указывается используемая версия XML и кодировка символов. Пролог в файле XML не обязателен, но у большинства он есть. Вторая строка – просто комментарий. После нее первый тэг (в нашем примере это <domain>) называется корневым элементом документа. Он должен быть единственным. У любого элемента элементы уровня ниже называются дочерними, более высокого уровня – родительскими, а элементы одного уровня (с общим родителем) являются родственными. Эти отношения показаны на следующей странице. Например, в нашем файле libvirt узлы <type> и <boot> являются родственными, а <os> – родительский для них.

Обратите внимание, что пробелы в файле (отступы и новые строки) облегчают человеку просмотр иерархической структуры, но не дают вклада в значения. Например, разархивировав документ OpenOffice.org и взглянув на содержимое XML-файлов, вы не увидите там ни одного пробела или перевода строки!


Поиск в документах XML

Большинство языков программирования предоставляют расширения для перемещения по документу XML или для поиска узлов, отвечающих указанному критерию. В командной строке утилита Linux xpath отыщет узлы в XML-файле, отвечающие данному выражению. Выражения немного напоминают шаблоны для имен файлов, и немного – регулярные выражения. Ниже дана таблица с кратким введением в выражения Xpath.

Вот несколько примеров поиска Xpath, который можно провести в нашем файле-примере из libvirt:

$ xpath -e //memory example.xml
Found 1 nodes in example.xml:
-- NODE --
<memory>262144</memory>
     
$ xpath -e “//disk/target[@dev='hda']” example.xml
Found 1 nodes in example.xml:
-- NODE --
<target dev=”hda” bus=”ide” />

На ранних стадиях развития HTML web-разработчики не особо заботились о синтаксисе. Они забывали про закрывающие тэги и сравнительно вольно обращались со вложением элементов. Web-браузерам приходилось учиться быть толерантными и извлекать из кода наибольший смысл, по возможности. Требования XML к синтаксису гораздо строже.

Про документ, который следует основным правилам синтаксиса, говорят, что он «правильно построен» [well-formed]. Это значит, что всем начальным тэгам соответствуют конечные тэги, тэги вложены правильно, значения атрибутов взяты в кавычки, специальные символы, типа < и >, не встречаются в других частях документа, и так далее. Вам, наверно, уже попадались и XHTML – это, в сущности, переформулировка HTML в более строгих синтаксических правилах XML.

Документы также бывают «действительными» [valid]. Это звание посерьезнее. Действительный документ – тот, что следует четкой спецификации. Спецификация может, например, установить, что элементы с именами <disk>, <interface> и <video> должны входить (именно в таком порядке) в элемент под названием <devices> и что элемент <video> должен задавать атрибуты type и vram.

Если расположить эти элементы в неправильном порядке или опустить атрибуты, то валидации документа не произойдет. Здесь-то XML и обходит традиционные текстовые файлы настройки, обычно используемые в Linux, поскольку любой более-менее приличный XML-редактор позволяет на лету привести ваш документ в соответствие со схемой.

Самым первым способом, применявшимся для спецификации структуры действительного XML-документа, включая список всех разрешенных элементов и их атрибутов, были определения типа документа [Document Type Definition, DTD]. Файлы DTD были, однако, тоже XML-документами. Они все еще используются, но почти везде заменяются на XML-схемы, которые обычно расположены в файлах XSD и являются документами XML.

В используемом нами примере из libvirt схемы пока нет (становится интересно, так ли сильна приверженность XML к libvirt; но я отвлекся). Чтобы обойти это, перейдем к новому, очень простому примеру. Во-первых, вот «целевой» файл (тот, который мы будем делать действительным):

<?xml version=”1.0”?>
 
<message xmlns=”mynamespace”
xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”
xsi:schemaLocation=”mynamespace message.xsd”>
<to> Graham </to>
<from> Chris </from>
<heading> Deadline </heading>
<body> I am running late this month! </body>
</message>

Можно заметить, что корневой элемент называется <message>, а элементы внутри него носят имена <to>, <from>, <heading> и <body>. Элемент <message> содержит некие атрибуты, определяющие пространство имен, которому должны принадлежать названия элементов. Пространство имен предотвращает (например) перепутывание моего элемента <heading> с любым из элементов <heading> других. Для простоты я назвал это пространство имен mynamespace, но на практике здесь обычно используют URL организации, для гарантии его уникальности. Элемент <message> также содержит атрибут, говорящий, где располагается схема (файл XSD). В нашем примере целевой файл и файл XSD расположены в одном каталоге.

Вот как выглядит схема:

<?xml version=”1.0”?>
<xs:schema xmlns:xs=”http://www.w3.org/2001/XMLSchema”
targetNamespace=”mynamespace”
xmlns=”mynamespace”
elementFormDefault=”qualified”>
<xs:element name=”message”>
   
<xs:complexType>
<xs:sequence>
<xs:element name=”to” type=”xs:string”/>
<xs:element name=”from” type=”xs:string”/>
<xs:element name=”heading” type=”xs:string”/>
<xs:element name=”body” type=”xs:string”/>
</xs:sequence>
</xs:complexType>
  
</xs:element>
</xs:schema>

Главная часть расположена внутри тэга <xs:element>. Можно видеть, что в тэге <message> ожидаются элементы под названиями <to>, <from>, <heading>, <body>, в приведенном порядке. XML-редакторы автоматически определяют схему и делают файл действительным для нее. На снимке экрана с XML Copy Editor видно, что файл не прошел валидацию из-за использования элемента <recipient> вместо элемента <to>.

С файлом XSD можно проделать много больше, чем показано здесь: например, прописать тип данных внутри элемента (строка, целое, дата и так далее), а также определить обязательные и опционные атрибуты для каждого элемента, задать имена атрибутам по умолчанию... Надеюсь, общую идею вы уловили.


Преобразование

Использованный мною пример был файлом libvirt config. Однако XML применяется в основном для определения содержимого документа (отчета, электронной таблицы или любого фрагмента документации) в виде, преобразуемом в другие форматы, такие как HTML для просмотра в браузере или PDF для распечатки. Для определения преобразования используются файлы XSLT.

XSLT означает «Extensible Stylesheet Language Transformations» [язык преобразования XML-документов], и они немного похожи на файлы CSS – тем, что в них указываются стили, применяемые для определенных элементов документа. Если вы хотите, улучив 10 минут, разобраться с XSLT, зайдите на www.w3schools.com, а затем по ссылке «Learn XSLT», и нажмите на кнопку «Try it yourself». Здесь можно поиграть с содержимым документа XML и связанным с ним XSLT и посмотреть на результат.

Снимок экрана на рисунке вверху дает хороший пример работы XSLT. Здесь Serna Free XML Editor от Syntext предоставляет WYSIWYG-редактирование документа XML. В правой панели показано содержимое текущего документа (после преобразования в HTML с помощью стилевой таблицы), а в панели слева – древовидная структура самого XML. Лично мне особенно нравится здесь то, что «сырое» содержимого XML не показывается!


Запросы Xpath без мистики
ЗАПРОС XPATH ЧЕМУ ОН СООТВЕТСТВУЕТ
/A Все элементы A в корне документа
//A Все элементы A по всему документу
//A/B Все элементы B, дочерние по отношению к элементам A, по всему документу
//A[B/FOO='BAR'] Все элементы A по всему документу, имеющие дочерний элемент B, у которого есть дочерний элемент FOO со значением BAR
//A/B[../FOO='BAR'] Все элементы B, дочерние к узлам A и у которых есть родственный элемент FOO со значением BAR
//A[@FOO='BAR'] Все элементы A, у которых есть атрибут FOO со значением BAR
Персональные инструменты
купить
подписаться
Яндекс.Метрика