Примечание: Мне пришлось собрать это вместе в системе BSD, которая могла иметь выходной формат последний
, отличный от вашего. Вывод last
в моей системе выглядит следующим образом:
guido ttys000 Wed Apr 6 18:44 - 18:44 (00:00)
guido ttys000 Wed Apr 6 14:36 - 14:55 (00:18)
guido ttys000 Wed Apr 6 13:56 - 14:33 (00:37)
...
Следовательно, вам, вероятно, потребуется изменить некоторые спецификаторы полей в приведенном ниже коде awk
, чтобы они соответствовали выводам последний -a
в вашей системе.
Тем не менее, вот мой подход, который полагается на awk
только для выполнения работы:
#!/bin/bash
last | awk '
# Skip final 2 lines of output
# (empty line followed by "wtmp begins..."
/^$/ { exit }
# Increment connections per user
# Increment connections per user+ip combination
{
# Possibly need to change $1 and $2 to other field numbers
# depending on output of your "last"
user[$1] ++;
userip[$1,$2] ++;
}
# For each user, print total and scan user+ip array
# for user+ip totals accumulated for this user
END {
for (u in user) {
print u " : " user[u];
for (idx in userip) {
split(idx, arr, SUBSEP);
if (arr[1] == u) print "\t" arr[2] " - " userip[idx];
}
}
}
'
Пример вывода:
root : 7
console - 7
guido : 682
console - 69
ttys000 - 446
...
Вы можете выполнить простую команду curl
в задании cron, но я рекомендую вам начать использовать решение для мониторинга с возможностями веб-мониторинга.Их много бесплатно, просто погуглите «Решения для веб-мониторинга с открытым исходным кодом», и вы получите их много!
Если вы действительно просматриваете файлы, вы можете выполнить запрос HEAD по URL-адресу, и сервер должен вернуть ключ («etag»), который сообщит вам, изменился ли файл. На сервере Apache это основано на ctime
файла, поэтому тег etag может измениться, даже если файл не изменился.
Но поскольку для меня сеть, вероятно, дороже записи на диск, если вы загружаете содержимое файла, вы можете просто сохранить его на диск.
Вы не говорите, сколько файлов и насколько они велики. Если существует большое количество файлов или файлов требуется очень много времени для загрузки этого сценария или если вы хотите поместить минимальную нагрузку на сервер, этот сценарий следует изменить так, чтобы каждый запрос выполнялся один раз в минуту или так часто. по возможности, если загрузка занимает больше минуты.
Ниже приведен очень простой сценарий Ruby, который, я думаю, сделает то, что вы хотите:
#! / Usr / bin / env ruby
require 'getoptlong'
require 'net/https'
require 'json'
require 'fileutils'
def main(roots, **options)
cache = Hash.new
cache = Hash.new
ok = true
path = options[:path]
while (ok)
roots.each do |root|
uri = URI.parse(root)
http = Net::HTTP.new(uri.host, uri.port)
case uri.scheme
when 'https'
http.use_ssl = true
http.verify_mode = OpenSSL::SSL::VERIFY_NONE
when 'http'
else
raise "unknow type #{uri.to_s}"
end
need_get = true
if (c = cache[uri.request_uri])
response = http.request(Net::HTTP::Head.new(uri.request_uri))
if response.code.to_i == 200
if response['etag'] == c['etag']
need_get = false
end
end
end
if need_get
response = http.request(Net::HTTP::Get.new(uri.request_uri))
cache[uri.request_uri] = { 'etag' => response['etag'] }
filename = File.join(path, uri.request_uri)
need_write = true
if File.exist?(filename)
# you could check if the file changed here, but it does not save you much.
end
if need_write
File.open(filename, 'w') { |file| file.write(response.body) }
end
end
end
sleep 30
end
end
begin
main([http://example.com/ten.html, http://example.com/eleven], { path: "/tmp/downloaded_files" })
rescue => error
puts error
end
Прежде всего, для мониторинга я рекомендую вам использовать Nagios , исходный код ядра бесплатный, но если вам нужен графический интерфейс, вы должны заплатить за него, но это того стоит.
Вы также можете использовать Icinga , PRTG или что-то еще, что вам больше подходит.
Collectd (Collection Daemon) также является бесплатным инструментом мониторинга, который вы можете загрузить, используя yum
для производных от RHEL или apt-get
для основанных на Debian. Вы можете прочитать эту статью , если хотите использовать Collectd.
Что касается второй части вашего вопроса, для выполнения работы каждый раз x, когда x периодически меньше минуты, поскольку вы знаете, что не можете использовать Cronjobs, так как вы можете использовать некоторые уловки, объясненные Жилем в этом вопросе , чтобы делать то, что вы хотите.
Лучше иметь сценарий для того, что вам нужно, и запускать его вечно, даже при загрузке, если вам нужно. У вас может быть простой синтаксис, как показано ниже:
while true; do yourJob; sleep someTime; done
Или вы даже можете использовать несколько более сложных сценариев, в зависимости от того, что вам нужно.
Вы также можете использовать команду watch
. Например:
watch -n1 command
Он будет запускать вашу команду
каждую секунду и навсегда.
Как вы могли догадаться, вы также можете запустить свой сценарий оболочки с помощью watch
, если вам нужно, чтобы простой сценарий выполнялся каждые x раз меньше минуты, а не сложный.
Выбор за вами.
Это зависит от нескольких факторов.
Если у вас есть контроль на веб-сервере, проще всего было бы установить службу (RESTful?), Указывающую количество файлов, измененных с момента последней проверки или загрузки. Это минимизирует как передачу данных, так и нагрузку как на клиент, так и на сервер.Даже больше, если выгрузку / изменение файлов на сервере можно напрямую отслеживать, например в сценарии загрузки вместо того, чтобы полагаться на файловую систему.
Если последнее, я бы поискал какое-нибудь решение для мониторинга файлов, например famd
.
Если у вас нет контроля над сервером, вам необходимо получить модификации, прежде чем вы сможете их загрузить. Проще всего было бы использовать какую-нибудь утилиту веб-зеркалирования , такую как w3mir, поскольку они уже позаботятся о проверке / поставке заголовков ETag и Last-Modified / If-Modified-Since. Это означает, что вам придется выполнять меньше вызовов и, следовательно, вы сможете запускать утилиту чаще.
Что касается , как запускать утилиту, это зависит от того, где она запускается. Вы можете использовать задание cron на машине Unix или просто запускать его в цикле.
Однако, если вы сделаете первое, вам будет полезно установить какой-то семафор, чтобы предотвратить запуск процесса зеркалирования до завершения предыдущего экземпляра. Это может быть так просто, как создать файл блокировки:
if [ -r /tmp/mirror.lock ]; then
echo "lock file found" | logger -t webmirror
exit 0
fi
touch /tmp/mirror.lock
...whatever...
rm /tmp/mirror.lock
Но вам также придется поймать
любой сигнал, который может убить ваш скрипт, иначе в случае временной ошибки файл блокировки может остаться там и не позволяйте запускать все последующие экземпляры даже после устранения ошибки.
Или вы можете проверить, что файл блокировки не старше некоторого разумного количества, и удалить его, если он есть, или проверить, сколько экземпляров сценария найдено с помощью ps
(обычно один, текущий; если больше, текущий лучше прервать), и вообще обойтись без файла блокировки.
Как сказал FarazX, существует несколько решений для мониторинга, таких как Nagios, Pandora FMS , ... Но, возможно, эти инструменты слишком велики для вашей цели. Возможно, вам хватит Uptimerobot .
Ознакомьтесь с предложениями и выберите лучшее для себя, но помните, что решение для мониторинга с большим количеством опций дает вам больше возможностей для вашей среды.