One place for hosting & domains

      для

      Использование ps, kill и nice для управления процессами в Linux


      Введение


      Сервер Linux, как и любой другой компьютер, использует приложения. Компьютер рассматривает эти приложения как процессы.

      Хотя Linux автоматически выполняет все скрытые низкоуровневые задачи жизненного цикла процесса, нам необходим способ взаимодействия с операционной системой для управления на более высоком уровне.

      В этом учебном модуле мы расскажем о некоторых простых аспектах управления процессами. Linux предоставляет широкий выбор инструментов для этой цели.

      В качестве примера мы используем Ubuntu 12.04 VPS, но любые современные дистрибутивы Linux будут работать аналогичным образом.

      Просмотр запущенных процессов в Linux


      top


      Чтобы посмотреть, какие процессы запущены на вашем сервере, нужно запустить команду top:

      top***
      
      top - 15:14:40 up 46 min,  1 user,  load average: 0.00, 0.01, 0.05 Tasks:  56 total,   1 running,  55 sleeping,   0 stopped,   0 zombie Cpu(s):  0.0%us,  0.0%sy,  0.0%ni,100.0%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   1019600k total,   316576k used,   703024k free,     7652k buffers Swap:        0k total,        0k used,        0k free,   258976k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND               1 root      20   0 24188 2120 1300 S  0.0  0.2   0:00.56 init                   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd               3 root      20   0     0    0    0 S  0.0  0.0   0:00.07 ksoftirqd/0            6 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 migration/0            7 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 watchdog/0             8 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset                 9 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper               10 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs          
      

      В верхней части подборки приведена статистика по системе, в том числе сведения о нагрузке и общем количестве задач.

      Вы можете легко увидеть, что в системе запущен 1 процесс, а 55 процессов находятся в режиме сна (т. е. не активны/не используют ресурсы ЦП).

      В нижней части отображаются запущенные процессы и статистика их использования.

      htop


      В репозиториях доступна улучшенная версия top, которая называется htop. Установите ее с помощью следующей команды:

      sudo apt-get install htop
      

      Если мы запустим команду htop, мы увидим отображение информации в более удобном формате:

      htop***
      
        Mem[|||||||||||           49/995MB]     Load average: 0.00 0.03 0.05   CPU[                          0.0%]     Tasks: 21, 3 thr; 1 running   Swp[                         0/0MB]     Uptime: 00:58:11   PID USER      PRI  NI  VIRT   RES   SHR S CPU% MEM%   TIME+  Command  1259 root       20   0 25660  1880  1368 R  0.0  0.2  0:00.06 htop     1 root       20   0 24188  2120  1300 S  0.0  0.2  0:00.56 /sbin/init   311 root       20   0 17224   636   440 S  0.0  0.1  0:00.07 upstart-udev-brid   314 root       20   0 21592  1280   760 S  0.0  0.1  0:00.06 /sbin/udevd --dae   389 messagebu  20   0 23808   688   444 S  0.0  0.1  0:00.01 dbus-daemon --sys   407 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.02 rsyslogd -c5   408 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   409 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.00 rsyslogd -c5   406 syslog     20   0  243M  1404  1080 S  0.0  0.1  0:00.04 rsyslogd -c5   553 root       20   0 15180   400   204 S  0.0  0.0  0:00.01 upstart-socket-br
      

      Вы можете узнать больше об использовании top и htop здесь.

      Использование ps для вывода перечня процессов


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

      Однако эти инструменты не всегда достаточно гибкие, чтобы охватывать все сценарии. Решить эту проблему может помочь мощная команда ps.

      При вызове без аргументов вывод может быть довольно сжатым:

      ps***
      
        PID TTY          TIME CMD  1017 pts/0    00:00:00 bash  1262 pts/0    00:00:00 ps
      

      Вывод показывает все процессы, связанные с текущим пользователем и текущим сеансом терминала. Это имеет смысл, потому что мы запускаем на этом терминале только bash и ps.

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

      ps aux***
      
      USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND root         1  0.0  0.2  24188  2120 ?        Ss   14:28   0:00 /sbin/init root         2  0.0  0.0      0     0 ?        S    14:28   0:00 [kthreadd] root         3  0.0  0.0      0     0 ?        S    14:28   0:00 [ksoftirqd/0] root         6  0.0  0.0      0     0 ?        S    14:28   0:00 [migration/0] root         7  0.0  0.0      0     0 ?        S    14:28   0:00 [watchdog/0] root         8  0.0  0.0      0     0 ?        S<   14:28   0:00 [cpuset] root         9  0.0  0.0      0     0 ?        S<   14:28   0:00 [khelper] . . .
      

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

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

      ps axjf***
      
       PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND     0     2     0     0 ?           -1 S        0   0:00 [kthreadd]     2     3     0     0 ?           -1 S        0   0:00  _ [ksoftirqd/0]     2     6     0     0 ?           -1 S        0   0:00  _ [migration/0]     2     7     0     0 ?           -1 S        0   0:00  _ [watchdog/0]     2     8     0     0 ?           -1 S<       0   0:00  _ [cpuset]     2     9     0     0 ?           -1 S<       0   0:00  _ [khelper]     2    10     0     0 ?           -1 S        0   0:00  _ [kdevtmpfs]     2    11     0     0 ?           -1 S<       0   0:00  _ [netns] . . .
      

      Как видите, процесс kthreadd отображается как родитель процесса ksoftirqd/0 и других процессов.

      Примечание об идентификаторах процессов


      В системах Linux и Unix каждому процессу назначается идентификатор процесса или PID. Операционная система использует их для идентификации и отслеживания процессов.

      Чтобы быстро узнать PID процесса, вы можете использовать команду pgrep:

      pgrep bash***
      
      1017
      

      Эта команда просто запросит идентификатор процесса и выведет его.

      Процессу init, который создается первым при загрузке, присваивается PID “1”.

      pgrep init***
      
      1
      

      Этот процесс отвечает за создание всех остальных процессов в системе. Последующим процессам присваиваются большие номера PID.

      Родитель процесса — это процесс, который отвечает за его создание. Родительские процессы имеют идентификатор PPID, который можно увидеть в заголовках столбцов многих приложений для управления процессами, включая top, htop и ps.

      Любое взаимодействие между пользователем и операционной системой, связанное с процессами, включает взаимное преобразование имен процессов и PID. Именно поэтому утилиты сообщают вам PID.

      Отношения родительских и дочерних элементов


      Создание дочернего процесса осуществляется в два этапа: fork() создает новое адресное пространство и копирует в него ресурсы, принадлежащие родительскому процессу, с помощью copy-on-write; а exec() загружает исполняемый блок в адресное пространство и выполняет его.

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

      Отправка сигналов процессам в Linux


      Все процессы Linux реагируют на сигналы. Операционная система использует сигналы, чтобы отправить программам команду остановиться или изменить поведение.

      Отправка сигналов процессам по PID


      Наиболее распространенный способ передачи сигналов в программу — использовать команду kill.

      Как вы можете догадаться, по умолчанию эта утилита пытается уничтожить процесс:

      <pre>kill <span class=“highlight”>PIDoftarget_process</span></pre>

      Она отправляет процессору сигнал TERM. Сигнал TERM просит процесс остановиться. Это позволяет программе выполнить операции по очистке и нормально завершить работу.

      Если программа работает неправильно и не завершает работу после получения сигнала TERM, мы можем отправить сигнал более высокого уровня — KILL:

      <pre>kill -KILL <span class=“highlight”>PIDoftarget_process</span></pre>

      Это специальный сигнал, который не отправляется программе.

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

      Каждому сигналу присвоено число, которое можно передать вместо имени. Например, вы можете передать “-15” вместо “-TERM” и “-9” вместо “-KILL”.

      Использование сигналов для других целей


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

      Например, многие демоны перезапускаются при получении сигнала HUP или прекращения работы. Например, так работает Apache.

      <pre>sudo kill -HUP <span class=“highlight”>pidofapache</span></pre>

      Получив вышеуказанную команду, Apache перезагрузит файл конфигурации и возобновит вывод контента.

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

      kill -l***
      
      1) SIGHUP    2) SIGINT   3) SIGQUIT  4) SIGILL   5) SIGTRAP  6) SIGABRT  7) SIGBUS   8) SIGFPE   9) SIGKILL 10) SIGUSR1 11) SIGSEGV 12) SIGUSR2 13) SIGPIPE 14) SIGALRM 15) SIGTERM . . .
      

      Отправка сигналов процессам по имени


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

      Команда pkill работает практически точно так же как и kill, но использует имя процесса:

      pkill -9 ping
      

      Вышеуказанная команда эквивалентна команде:

      kill -9 `pgrep ping`
      

      Если вы хотите отправить сигнал каждому экземпляру определенного процесса, вы можете использовать команду killall:

      killall firefox
      

      Приведенная выше команда отправит сигнал TERM всем экземплярам firefox, запущенным на этом компьютере.

      Настройка приоритетов процессов


      Часто бывает необходимо изменить приоритет процессов в серверной среде.

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

      Linux контролирует приоритеты с помощью значения вежливости.

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

      Когда мы запускали команду top в начале этого учебного модуля, мы видели столбец “NI”. В этом столбце отображается значение вежливости процесса:

      top***
      
       Tasks:  56 total,   1 running,  55 sleeping,   0 stopped,   0 zombie Cpu(s):  0.0%us,  0.3%sy,  0.0%ni, 99.7%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st Mem:   1019600k total,   324496k used,   695104k free,     8512k buffers Swap:        0k total,        0k used,        0k free,   264812k cached   PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND            1635 root      20   0 17300 1200  920 R  0.3  0.1   0:00.01 top                    1 root      20   0 24188 2120 1300 S  0.0  0.2   0:00.56 init                   2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd               3 root      20   0     0    0    0 S  0.0  0.0   0:00.11 ksoftirqd/0
      

      В зависимости от системы, значения вежливости могут различаться от “-19/-20” (наибольший приоритет) до “19/20” (наименьший приоритет).

      Чтобы запустить программу с определенным значением вежливости, мы можем использовать команду nice:

      <pre>nice -n 15 <span class=“highlight”>commandtoexecute</span></pre>

      Это работает только в начале новой программы.

      Чтобы изменить значение вежливости уже выполняемой программы, мы используем инструмент renice:

      <pre>renice 0 <span class=“highlight”>PIDtoprioritize</span></pre>

      Примечание. Хотя nice по необходимости использует имя команды, renice вызывает PID процесса.

      Заключение


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

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

      <div class=“author”>Джастин Эллингвуд</div>



      Source link

      Использование Journalctl для просмотра журналов Systemd и выполнения операций с ними


      Введение

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

      Журнальная система реализована в форме демона journald, который обрабатывает все сообщения ядра, initrd, служб и т. д. В этом учебном руководстве мы покажем, как использовать утилиту journalctl для доступа данными в журнале и управления этими данными.

      Общая идея

      Одна из целей журнальной системы systemd заключается в централизации управления журналами вне зависимости от источника сообщений. Поскольку существенная часть процесса загрузки и управления службами выполняется процессом systemd, имеет смысл стандартизировать сбор данных для журналов и доступ к ним. Демон journald собирает данные из всех доступных источников и сохраняет их в двоичном формате для удобного и динамичного управления ими.

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

      Хранение данных журнала в двоичном формате также означает, что данные можно отображать в произвольном виде в зависимости от того, что требуется в текущий момент. Например, для каждодневного управления журналами вы можете использовать стандартный формат syslog, но если вы захотите составить график перебоев в работе служб, вы можете вывести все записи в формате объектов JSON для экспорта в приложение составления графиков. Поскольку данные не записываются на диск в формате обычного текста, их не нужно будет конвертировать, если вам потребуется другой формат вывода.

      Журнальную систему systemd можно использовать вместе с существующей реализацией syslog, или в качестве функциональной замены syslog, если вам это потребуется. Хотя журнальная система systemd способна удовлетворить большинство потребностей администратора, ее также можно использовать в качестве дополнения к существующим механизмам ведения журнала. Например, вы можете использовать централизованный сервер syslog для компиляции данных с нескольких серверов, но при этом также чередовать журналы нескольких служб одной системы с журналом systemd. Объединив эти технологии, вы можете выполнить обе задачи.

      Настройка времени системы

      Одно из преимуществ использования двоичного журнала заключается в возможности просмотра записей журнала как с локальным временем, так и с временем по Гринвичу (UTC). По умолчанию systemd использует для отображения результатов локальное время.

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

      Прежде всего, нужно использовать опцию list-timezones для просмотра доступных часовых поясов:

      timedatectl list-timezones
      

      Эта опция выводит список часовых поясов, доступных в вашей системе. Когда вы найдете часовой пояс, соответствующий расположению вашего сервера, вы сможете установить его с помощью опцииset-timezone:

      sudo timedatectl set-timezone zone
      

      Чтобы убедиться, что ваша система использует правильное время, воспользуйтесь командой timedatectl без опций или с опцией status. Изображение на экране будет таким же:

      timedatectl status
      
            Local time: Thu 2015-02-05 14:08:06 EST
        Universal time: Thu 2015-02-05 19:08:06 UTC
              RTC time: Thu 2015-02-05 19:08:06
             Time zone: America/New_York (EST, -0500)
           NTP enabled: no
      NTP synchronized: no
       RTC in local TZ: no
            DST active: n/a
      

      В первой строке должно отображаться правильное время.

      Основы просмотра журнала

      Чтобы просмотреть журналы, собранные демоном journald, используйте команду journalctl.

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

      journalctl
      
      -- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
      Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
      Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
      Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
      Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules
      
      . . .
      

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

      Данный формат будет знаком тем, кто привык к стандартным журналам syslog. Однако при этом способе данные собираются из большего числа источников, чем поддерживают стандартные приложения syslog. Журнальная система поддерживает журналы процесса начальной загрузки, ядра, initrd, стандартные журналы ошибок и вывода приложений и т. д.

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

      Если вы хотите вывести временные метки в формате UTC, вы можете использовать флаг --utc:

      journalctl --utc
      

      Фильтрация журнала по времени

      Хотя доступ к такому большому набору данных несомненно полезен, просмотреть и понять такое количество информации может быть очень сложно или даже невозможно. Поэтому опции фильтрации входят в число наиболее значимых возможностей journalctl.

      Вывод журналов текущей загрузки

      Флаг -b — одна из самых простых опций, которой вы часто будете пользоваться. С его помощью вы сможете вывести для просмотра все записи журнала, собранные с момента последней перезагрузки.

      journalctl -b
      

      Это поможет вам определять, какая информация важна для текущей среды, и управлять этой информацией.

      Если вы не используете эту функцию и выводите данные более, чем за один день загрузок, вы увидите, что утилита journalctl вставляет примерно такую строку при каждом выключении системы:

      . . .
      
      -- Reboot --
      
      . . .
      

      Ее можно использовать в качестве логического разделителя информации между сеансами загрузки.

      Прошлые загрузки

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

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

      • sudo mkdir -p /var/log/journal

      Также вы можете отредактировать файл конфигурации журнальной системы:

      • sudo nano /etc/systemd/journald.conf

      В разделе [Journal] установите для опции Storage= значение persistent, чтобы включить постоянное хранение журналов:

      /etc/systemd/journald.conf

      . . .
      [Journal]
      Storage=persistent
      

      Если на вашем сервере включено хранение журналов предыдущих сеансов загрузки, утилита journalctl предоставит ряд команд, которые помогут работать с сеансами загрузки как с единицами хранения. Чтобы просмотреть сеансы загрузки, о которых известно journald, используйте опцию --list-boots с командой journalctl:

      journalctl --list-boots
      
      -2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
      -1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
       0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC
      

      С этой опцией команда будет выводить по одной строке для каждого сеанса загрузки. Первый столбец — это относительный идентификатор сеанса загрузки, который удобно использовать для ссылки на сеанс загрузки с помощью journalctl. Если вам требуется абсолютный идентификатор, используйте значение boot ID во втором столбце. Два поля времени ближе к концу строки позволяют определить время сеанса загрузки.

      Чтобы вывести информацию из этих сеансов загрузки, вы можете использовать информацию из первого или второго столбца.

      Например, чтобы просмотреть журнал предыдущей загрузки, используйте относительный указатель -1 с флагом -b:

      journalctl -b -1
      

      Также вы можете использовать идентификатор сеанса загрузки для получения данных по сеансу загрузки:

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe
      

      Временные окна

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

      Для фильтрации временных окон можно использовать опции --since и --until, которые ограничивают вывод записями после или до указанного времени соответственно.

      Значения времени могут иметь разные форматы. Для абсолютных значений времени нужно использовать следующий формат:

      YYYY-MM-DD HH:MM:SS
      

      Например, чтобы просмотреть все записи с 10 января 2015 г. 17:15, мы введем:

      journalctl --since "2015-01-10 17:15:00"
      

      Если какие-то компоненты вышеописанного формата будут пропущены, будут применены значения по умолчанию. Например, если дата не будет указана, по умолчанию будет использоваться текущая дата. Если компонент времени отсутствует, для замены будет использоваться значение “00:00:00” (полночь). Поле секунд можно опустить, и тогда для него будет по умолчанию использовано значение “00”:

      journalctl --since "2015-01-10" --until "2015-01-11 03:00"
      

      Журнальная система также понимает определенные относительные значения и именованные ярлыки. Например, вы можете использовать слова “yesterday” (вчера), “today” (сегодня), “tomorrow”(завтра), “now” (сейчас) и т. д. Чтобы указать относительное время, следует использовать префикс «-» или «+» перед числовым значением или использовать такие слова, как «ago» (назад) при построении фраз.

      Чтобы получить данные за вчерашний день, введите:

      journalctl --since yesterday
      

      Если вы получили отчеты о перебоях в работе службы, которые начались в 9:00 и закончились час назад, вы можете ввести следующую команду:

      journalctl --since 09:00 --until "1 hour ago"
      

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

      Фильтрация по значимости сообщений

      Мы изучили несколько возможных способов фильтрации записей в журнальной системе по временным рамкам. В этом разделе мы поговорим о фильтрации сообщений по значимым для вас службам или компонентам. Журнал systemd предоставляет много разных способов делать это.

      По единицам

      Возможно одним из наиболее полезных способов фильтрации является фильтрация по единицам, которые вас интересуют. Для такой фильтрации мы можем использовать опцию -u.

      Например, чтобы посмотреть все журналы единицы Nginx в нашей системе, мы можем ввести команду:

      journalctl -u nginx.service
      

      Обычно при этом также используется фильтрация по времени, чтобы вывести строки, которые вас интересуют. Например, чтобы проверить, как служба работает сегодня, можно ввести команду:

      journalctl -u nginx.service --since today
      

      Такая фокусировка особенно полезна, если вы используете возможности чередования записей разных единиц в журнальной системе. Например, если ваш процесс Nginx использует единицу PHP-FPM для обработки динамического контента, вы можете объединить их данные в хронологическом порядке, указав обе единицы:

      journalctl -u nginx.service -u php-fpm.service --since today
      

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

      По процессу, пользователю или идентификатору группы

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

      Для этого нужно указать при фильтрации поле _PID. Например, если нас интересует PID 8088, мы можем ввести:

      journalctl _PID=8088
      

      В других случаях нам может понадобиться вывести все записи, зарегистрированные для определенного пользователя или группы. Это можно сделать с помощью фильтров _UID или _GID. Например, если ваш веб-сервер работает под именем пользователя www-data, вы можете найти идентификатор пользователя с помощью следующей команды:

      id -u www-data
      
      33
      

      После этого, вы сможете использовать возвращенный идентификатор для фильтрации результатов журнальной системы:

      journalctl _UID=33 --since today
      

      Журнал systemd содержит множество полей, которые можно использовать для фильтрации. Некоторые из них передаются от регистрируемого процесса и применяются journald с использованием информации, собираемой из системы в указанное в журнале время.

      Символ подчеркивания в начале указывает, что поле _PID относится к последнему типу. Журнал автоматически регистрирует и индексирует значения PID процессов, регистрируемых для последующей фильтрации. Вы можете узнать все о доступных полях журнала, используя следующую команду:

      man systemd.journal-fields
      

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

      Например, чтобы посмотреть, для каких идентификаторов групп существуют записи в журнальной системе systemd, вы можете ввести следующую команду:

      journalctl -F _GID
      
      32
      99
      102
      133
      81
      84
      100
      0
      124
      87
      

      Она покажет вам все значения, сохраненные в журнальной системе для поля group ID. Это должно помочь вам в настройке фильтров.

      По пути компонента

      Также для фильтрации можно указать путь.

      Если путь указывает на исполняемый файл, journalctl выведет все записи, связанные с этим исполняемым файлом. Например, чтобы найти записи с исполняемым файлом bash, нужно ввести команду:

      journalctl /usr/bin/bash
      

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

      Отображение сообщений ядра

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

      Чтобы вывести только эти сообщения, можно добавить к команде флаг -k или --dmesg:

      journalctl -k
      

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

      journalctl -k -b -5
      

      По приоритету

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

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

      Например, чтобы вывести только записи с уровнем серьезности error (ошибка) или выше, введите команду:

      journalctl -p err -b
      

      Эта команда покажет вам все сообщения с пометкой error (ошибка), critical (критическая ошибка), alert (тревога) или emergency (чрезвычайная ситуация). В журнальной системе реализованы стандартные уровни ошибок syslog. Вы можете использовать название уровня приоритета или соответствующее числовое значение. Вот эти значения, от наибольшего приоритета к наименьшему:

      • 0: emerg
      • 1: alert
      • 2: crit
      • 3: err
      • 4: warning
      • 5: notice
      • 6: info
      • 7: debug

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

      Изменение отображения журнальной системы

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

      Сокращение или расширение области вывода

      Мы можем настроить вид вывода данных journalctl, указав, что вывод можно сжать или раскрыть.

      По умолчанию journalctl выводит на страничном модуле всю запись целиком так, что записи доходят до правого края экрана. Для доступа к этой информации следует нажать правую стрелку.

      Если вы предпочитаете урезать вывод и вставить многоточие в месте, где удалена информация, вы можете использовать опцию --no-full:

      journalctl --no-full
      
      . . .
      
      Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
      Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
      Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot
      

      Также вы можете сделать и обратное, и попросить journalctl вывести всю доступную информацию вне зависимости от того, содержит ли она непечатные символы. Для этого можно использовать флаг -a:

      journalctl -a
      

      Вывод в стандартный выход

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

      Для такого вывода следует использовать опцию --no-pager:

      journalctl --no-pager
      

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

      Форматы вывода

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

      Например, чтобы вывести журнала в формате JSON, нужно ввести следующую команду:

      journalctl -b -u nginx -o json
      
      { "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }
      
      . . .
      

      Это полезно, если вы используете утилиты для синтаксического анализа. Вы можете использовать формат json-pretty, чтобы сделать структуру данных проще, прежде чем передавать данные потребителю JSON:

      journalctl -b -u nginx -o json-pretty
      
      {
          "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
          "__REALTIME_TIMESTAMP" : "1422990364739502",
          "__MONOTONIC_TIMESTAMP" : "27200938",
          "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
          "PRIORITY" : "6",
          "_UID" : "0",
          "_GID" : "0",
          "_CAP_EFFECTIVE" : "3fffffffff",
          "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
          "_HOSTNAME" : "desktop",
          "SYSLOG_FACILITY" : "3",
          "CODE_FILE" : "src/core/unit.c",
          "CODE_LINE" : "1402",
          "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
          "SYSLOG_IDENTIFIER" : "systemd",
          "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
          "_TRANSPORT" : "journal",
          "_PID" : "1",
          "_COMM" : "systemd",
          "_EXE" : "/usr/lib/systemd/systemd",
          "_CMDLINE" : "/usr/lib/systemd/systemd",
          "_SYSTEMD_CGROUP" : "/",
          "UNIT" : "nginx.service",
          "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
          "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
      }
      
      . . .
      

      Для отображения можно использовать следующие форматы:

      • cat: отображает только само поле сообщения.
      • export: двоичный формат, подходящий для передачи или резервного копирования.
      • json: стандартный формат JSON с одной записью на строку.
      • json-pretty: код JSON в формате, более удобном для чтения человеком
      • json-sse: вывод в формате JSON в оболочке, совместимой с операцией add server-sent event
      • short: вывод в формате syslog по умолчанию
      • short-iso: формат по умолчанию, дополненный для отображения временных меток часов ISO 8601.
      • short-monotonic: формат по умолчанию с однотонными временными метками.
      • short-precise: формат по умолчанию с точностью до микросекунд
      • verbose: показывает все поля журнальной системы, доступные для ввода, в том числе те, которые обычно скрыты на внутреннем уровне.

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

      Мониторинг активных процессов

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

      Отображение последних журналов

      Чтобы вывести указанное количество записей, вы можете использовать опцию -n, которая работает как tail -n.

      По умолчанию отображается 10 последних записей:

      journalctl -n
      

      Вы можете указать желаемое количество записей, задав число после -n:

      journalctl -n 20
      

      Наблюдение за журналами

      Для активного наблюдения за журналами по мере их пополнения можно использовать флаг -f. Это будет работать именно так, как можно ожидать, если у вас есть опыт использования tail -f:

      journalctl -f
      

      Обслуживание журналов

      Вам может быть интересно, сколько места занимают все эти данные, которые мы уже видели. Более того, вы можете захотеть удалить какие-либо старые журналы и освободить место.

      Определение текущего использования дискового пространства

      Вы можете определить, сколько места занимает журнал на диске, используя флаг --disk-usage:

      journalctl --disk-usage
      
      Journals take up 8.0M on disk.
      

      Удаление старых журналов

      Если вы хотите сократить размер журнала, вы можете использовать для этого два разных способа (доступных в systemd версии 218 или выше).

      Если вы используете опцию --vacuum-size, вы можете сократить журнал, указав размер. При использовании этой опции старые записи будут удаляться, пока занимаемое журнальной системой место на диске не сократится до требуемого размера:

      sudo journalctl --vacuum-size=1G
      

      Также можно сократить размер журнала, указав время отсечки с помощью --vacuum-time. Любые записи вне этого времени удаляются. Эта опция позволяет сохранить записи, созданные после истечения определенного времени.

      Например, чтобы сохранить записи с прошлого года, вы можете ввести:

      sudo journalctl --vacuum-time=1years
      

      Ограничение расширения журналов

      Вы можете настроить свой сервер так, чтобы ограничить место, занимаемое журнальной системой. Для этого следует отредактировать файл /etc/systemd/journald.conf.

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

      • SystemMaxUse=: указывает максимальное пространство на диске, которое может использоваться журнальной системой.
      • SystemKeepFree=: указывает пространство на диске, которое журнальная система должна оставлять свободным при добавлении записей в журналы.
      • SystemMaxFileSize=: определяет, до какого размера могут увеличиваться большие файлы журнала на диске до ротации.
      • RuntimeMaxUse=: указывает, сколько места на диске может использоваться для временного хранения (в /run filesystem).
      • RuntimeKeepFree=: указывает, сколько места на диске следует оставлять на диске для других целей при записи данных во временное хранилище (в файловой системе /run).
      • RuntimeMaxFileSize=: указывает, сколько места может занимать отдельный файл журнала во временном хранилище (в файловой системе /run) до ротации.

      Задавая эти значения, вы можете контролировать, сколько места на вашем сервере использует journald. Помните, что SystemMaxFileSize и RuntimeMaxFileSize будут применяться к архивным файлам для достижения заданных ограничений. Это важно помнить при интерпретации подсчета файлов после операции вакуумной очистки.

      Заключение

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



      Source link

      Использование JavaScript Fetch API для получения данных


      Введение

      Было время, когда для запросов API использовался XMLHttpRequest. В нем не было промисов, и он не позволял создавать чистый код JavaScript. В jQuery мы использовали более чистый синтаксис с jQuery.ajax().

      Сейчас JavaScript имеется собственный встроенный способ отправки запросов API. Это Fetch API, новый стандарт создания серверных запросов с промисами, также включающий много других возможностей.

      В этом учебном модуле мы создадим запросы GET и POST, используя Fetch API.

      Предварительные требования

      Для этого обучающего модуля вам потребуется следующее:

      Шаг 1 — Введение в синтаксис Fetch API

      Чтобы использовать Fetch API, вызовите метод fetch, который принимает URL API в качестве параметра:

      fetch(url)
      

      После метода fetch() нужно включить метод промиса then():

      .then(function() {
      
      })
      

      Метод fetch() возвращает промис. Если возвращается промис resolve, будет выполнена функция метода then(). Эта функция содержит код для обработки данных, получаемых от API.

      Под методом then() следует включить метод catch():

      .catch(function() {
      
      });
      

      API, вызываемый с помощью метода fetch(), может не работать или на нем могут возникнуть ошибки. Если это произойдет, будет возвращен промис reject. Метод catch используется для обработки reject. Код метода catch() выполняется в случае возникновения ошибки при вызове выбранного API.

      В целом, использование Fetch API выглядит следующим образом:

      fetch(url)
      .then(function() {
      
      })
      .catch(function() {
      
      });
      

      Теперь мы понимаем синтаксис использования Fetch API и можем переходить к использованию fetch() с реальным API.

      Шаг 2 — Использование Fetch для получения данных от API

      Следующие примеры кода основаны на Random User API. Используя API, вы получаете десять пользователей и выводите их на странице, используя Vanilla JavaScript.

      Идея заключается в том, чтобы получить все данные от Random User API и вывести их в элементах списка внутри списка автора. Для начала следует создать файл HTML и добавить в него заголовок и неупорядоченный список с идентификатором authors:

      <h1>Authors</h1>
      <ul id="authors"></ul>
      

      Теперь добавьте теги script в конец файла HTML и используйте селектор DOM для получения ul. Используйте getElementById с аргументом authors. Помните, что authors — это идентификатор ранее созданного ul:

      <script>
      
          const ul = document.getElementById('authors');
      
      </script>
      

      Создайте постоянную переменную url, в которой будет храниться URL-адрес API, который вернет десять случайных пользователей:

      const url="https://randomuser.me/api/?results=10";
      

      Теперь у нас есть ul и url, и мы можем создать функции, которые будут использоваться для создания элементов списка. Создайте функцию под названием createNode, принимающую параметр с именем element:

      function createNode(element) {
      
      }
      

      Впоследствии, при вызове createNode, вам нужно будет передать имя создаваемого элемента HTML.

      Добавьте в функцию выражение return, возвращающее element, с помощью document.createElement():

      function createNode(element) {
          return document.createElement(element);
      }
      

      Также вам нужно будет создать функцию с именем append, которая принимает два параметра: parent и el:

      function append(parent, el) {
      
      }
      

      Эта функция будет добавлять el к parent, используя document.createElement:

      function append(parent, el) {
          return parent.appendChild(el);
      }
      

      Теперь и createNode, и append готовы к использованию. Используя Fetch API, вызовите Random User API, добавив к fetch() аргумент url:

      fetch(url)
      
      fetch(url)
        .then(function(data) {
      
          })
        })
        .catch(function(error) {
      
        });
      

      В вышеуказанном коде вы вызываете Fetch API и передаете URL в Random User API. После этого поступает ответ. Однако ответ вы получите не в формате JSON, а в виде объекта с серией методов, которые можно использовать в зависимости от того, что вы хотите делать с информацией. Чтобы конвертировать возвращаемый объект в формат JSON, используйте метод json().

      Добавьте метод then(), содержащий функцию с параметром resp:

      fetch(url)
      .then((resp) => )
      

      Параметр resp принимает значение объекта, возвращаемого fetch(url). Используйте метод json(), чтобы конвертировать resp в данные JSON:

      fetch(url)
      .then((resp) => resp.json())
      

      При этом данные JSON все равно необходимо обработать. Добавьте еще одно выражение then() с функцией, имеющей аргумент с именем data:

      .then(function(data) {
      
          })
      })
      

      Создайте в этой функции переменную с именем authors, принимающую значение data.results:

      .then(function(data) {
          let authors = data.results;
      

      Для каждого автора в переменной authors нам нужно создать элемент списка, выводящий портрет и имя автора. Для этого отлично подходит метод map():

      let authors = data.results;
      return authors.map(function(author) {
      
      })
      

      Создайте в функции map переменную li, которая будет равна createNode с li (элемент HTML) в качестве аргумента:

      return authors.map(function(author) {
          let li = createNode('li');
      })
      

      Повторите эту процедуру, чтобы создать элемент span и элемент img:

      let li = createNode('li');
      let img = createNode('img');
      let span = createNode('span');
      

      Предлагает имя автора и портрет, идущий вместе с именем. Установите в img.src портрет автора:

      let img = createNode('img');
      let span = createNode('span');
      
      img.src = author.picture.medium;
      

      Элемент span должен содержать имя и фамилию автора. Для этого можно использовать свойство innerHTML и интерполяцию строк:

      img.src = author.picture.medium;
      span.innerHTML = `${author.name.first} ${author.name.last}`;
      

      Когда изображение и элемент списка созданы вместе с элементом span, вы можете использовать функцию append, которую мы ранее добавили для отображения этих элементов на странице:

      append(li, img);
      append(li, span);
      append(ul, li);
      

      Выполнив обе функции then(), вы сможете добавить функцию catch(). Эта функция поможет зарегистрировать потенциальную ошибку на консоли:

      .catch(function(error) {
        console.log(error);
      });
      

      Это полный код запроса, который вы создали:

      function createNode(element) {
          return document.createElement(element);
      }
      
      function append(parent, el) {
        return parent.appendChild(el);
      }
      
      const ul = document.getElementById('authors');
      const url="https://randomuser.me/api/?results=10";
      
      fetch(url)
      .then((resp) => resp.json())
      .then(function(data) {
        let authors = data.results;
        return authors.map(function(author) {
          let li = createNode('li');
          let img = createNode('img');
          let span = createNode('span');
          img.src = author.picture.medium;
          span.innerHTML = `${author.name.first} ${author.name.last}`;
          append(li, img);
          append(li, span);
          append(ul, li);
        })
      })
      .catch(function(error) {
        console.log(error);
      });
      

      Вы только что успешно выполнили запрос GET, используя Random User API и Fetch API. На следующем шаге вы научитесь выполнять запросы POST.

      Шаг 3 — Обработка запросов POST

      По умолчанию Fetch использует запросы GET, но вы также можете использовать и все другие типы запросов, изменять заголовки и отправлять данные. Для этого нужно задать объект и передать его как второй аргумент функции fetch.

      Прежде чем создать запрос POST, создайте данные, которые вы хотите отправить в API. Это будет объект с именем data с ключом name и значением Sammy (или вашим именем):

      const url="https://randomuser.me/api";
      
      let data = {
        name: 'Sammy'
      }
      

      Обязательно добавьте постоянную переменную, хранящую ссылку на Random User API.

      Поскольку это запрос POST, ее нужно будет указать явно. Создайте объект с именем fetchData:

      let fetchData = {
      
      }
      

      Этот объект должен содержать три ключа: method, body и headers. Ключ method должен иметь значение 'POST'. Для body следует задать значение только что созданного объекта data. Для headers следует задать значение new Headers():

      let fetchData = {
        method: 'POST',
        body: data,
        headers: new Headers()
      }
      

      Интерфейс Headers является свойством Fetch API, который позволяет выполнять различные действия с заголовками запросов и ответов HTTP. Если вы захотите узнать об этом больше, вы можете найти более подробную информацию в статье под названием Определение маршрутов и методов запросов HTTP в Express.

      С этим кодом можно составлять запросы POST, используя Fetch API. Мы добавим url и fetchData как аргументы запроса fetch POST:

      fetch(url, fetchData)
      

      Функция then() будет включать код, обрабатывающий ответ, получаемый от сервера Random User API:

      fetch(url, fetchData)
      .then(function() {
          // Handle response you get from the server
      });
      

      Есть и другая опция, позволяющая создать объект и использовать функцию fetch(). Вместо того, чтобы создавать такой объект как fetchData, вы можете использовать конструктор запросов для создания объекта запроса. Для этого нужно создать переменную с именем request:

      const url="https://randomuser.me/api";
      
      let data = {
        name: 'Sara'
      }
      
      var request =
      

      Для переменной request следует задать значение new Request. Конструкт new Request принимает два аргумента: URL API (url) и объект. В объекте также должны содержаться ключи method, body и headers, как и в fetchData:

      var request = new Request(url, {
          method: 'POST',
          body: data,
          headers: new Headers()
      });
      

      Теперь request можно использовать как единственный аргумент для fetch(), поскольку он также включает URL-адрес API:

      fetch(request)
      .then(function() {
          // Handle response we get from the API
      })
      

      В целом код будет выглядеть следующим образом:

      const url="https://randomuser.me/api";
      
      let data = {
        name: 'Sara'
      }
      
      var request = new Request(url, {
          method: 'POST',
          body: data,
          headers: new Headers()
      });
      
      fetch(request)
      .then(function() {
          // Handle response we get from the API
      })
      

      Теперь вы знаете два метода создания и выполнения запросов POST с помощью Fetch API.

      Заключение

      Хотя Fetch API поддерживается еще не всеми браузерами, он представляет собой отличную альтернативу XMLHttpRequest. Если вы хотите узнать, как вызывать Web API с помощью React, ознакомьтесь с этой статьей по данной теме.



      Source link