Whamcloud - gitweb
LU-8066 misc: replace /proc with "lctl get/set_param"
[doc/manual.git] / LustreMonitoring.xml
1 <?xml version='1.0' encoding='UTF-8'?><chapter xmlns="http://docbook.org/ns/docbook" xmlns:xl="http://www.w3.org/1999/xlink" version="5.0" xml:lang="en-US" xml:id="lustremonitoring">
2   <title xml:id="lustremonitoring.title">Monitoring a Lustre File System</title>
3   <para>This chapter provides information on monitoring a Lustre file system and includes the
4     following sections:</para>
5   <itemizedlist>
6     <listitem>
7       <para><xref linkend="dbdoclet.50438273_18711"/>Lustre Changelogs</para>
8     </listitem>
9     <listitem>
10       <para><xref linkend="dbdoclet.jobstats"/>Lustre Jobstats</para>
11     </listitem>
12     <listitem>
13       <para><xref linkend="dbdoclet.50438273_81684"/>Lustre Monitoring Tool</para>
14     </listitem>
15     <listitem>
16       <para><xref linkend="dbdoclet.50438273_80593"/>CollectL</para>
17     </listitem>
18     <listitem>
19       <para><xref linkend="dbdoclet.50438273_44185"/>Other Monitoring Options</para>
20     </listitem>
21   </itemizedlist>
22   <section xml:id="dbdoclet.50438273_18711">
23       <title><indexterm><primary>change logs</primary><see>monitoring</see></indexterm>
24 <indexterm><primary>monitoring</primary></indexterm>
25 <indexterm><primary>monitoring</primary><secondary>change logs</secondary></indexterm>
26
27 Lustre Changelogs</title>
28     <para>The changelogs feature records events that change the file system
29     namespace or file metadata. Changes such as file creation, deletion,
30     renaming, attribute changes, etc. are recorded with the target and parent
31     file identifiers (FIDs), the name of the target, a timestamp, and user
32     information. These records can be used for a variety of purposes:</para>
33     <itemizedlist>
34       <listitem>
35         <para>Capture recent changes to feed into an archiving system.</para>
36       </listitem>
37       <listitem>
38         <para>Use changelog entries to exactly replicate changes in a file
39         system mirror.</para>
40       </listitem>
41       <listitem>
42         <para>Set up &quot;watch scripts&quot; that take action on certain
43         events or directories.</para>
44       </listitem>
45       <listitem>
46         <para>Audit activity on Lustre, thanks to user information associated to
47         file/directory changes with timestamps.</para>
48       </listitem>
49     </itemizedlist>
50     <para>Changelogs record types are:</para>
51     <informaltable frame="all">
52       <tgroup cols="2">
53         <colspec colname="c1" colwidth="50*"/>
54         <colspec colname="c2" colwidth="50*"/>
55         <thead>
56           <row>
57             <entry>
58               <para><emphasis role="bold">Value</emphasis></para>
59             </entry>
60             <entry>
61               <para><emphasis role="bold">Description</emphasis></para>
62             </entry>
63           </row>
64         </thead>
65         <tbody>
66           <row>
67             <entry>
68               <para> MARK</para>
69             </entry>
70             <entry>
71               <para> Internal recordkeeping</para>
72             </entry>
73           </row>
74           <row>
75             <entry>
76               <para> CREAT</para>
77             </entry>
78             <entry>
79               <para> Regular file creation</para>
80             </entry>
81           </row>
82           <row>
83             <entry>
84               <para> MKDIR</para>
85             </entry>
86             <entry>
87               <para> Directory creation</para>
88             </entry>
89           </row>
90           <row>
91             <entry>
92               <para> HLINK</para>
93             </entry>
94             <entry>
95               <para> Hard link</para>
96             </entry>
97           </row>
98           <row>
99             <entry>
100               <para> SLINK</para>
101             </entry>
102             <entry>
103               <para> Soft link</para>
104             </entry>
105           </row>
106           <row>
107             <entry>
108               <para> MKNOD</para>
109             </entry>
110             <entry>
111               <para> Other file creation</para>
112             </entry>
113           </row>
114           <row>
115             <entry>
116               <para> UNLNK</para>
117             </entry>
118             <entry>
119               <para> Regular file removal</para>
120             </entry>
121           </row>
122           <row>
123             <entry>
124               <para> RMDIR</para>
125             </entry>
126             <entry>
127               <para> Directory removal</para>
128             </entry>
129           </row>
130           <row>
131             <entry>
132               <para> RENME</para>
133             </entry>
134             <entry>
135               <para> Rename, original</para>
136             </entry>
137           </row>
138           <row>
139             <entry>
140               <para> RNMTO</para>
141             </entry>
142             <entry>
143               <para> Rename, final</para>
144             </entry>
145           </row>
146           <row>
147             <entry>
148               <para> OPEN *</para>
149             </entry>
150             <entry>
151               <para> Open</para>
152             </entry>
153           </row>
154           <row>
155             <entry>
156               <para> CLOSE</para>
157             </entry>
158             <entry>
159               <para> Close</para>
160             </entry>
161           </row>
162           <row>
163             <entry>
164               <para> LYOUT</para>
165             </entry>
166             <entry>
167               <para> Layout change</para>
168             </entry>
169           </row>
170           <row>
171             <entry>
172               <para> TRUNC</para>
173             </entry>
174             <entry>
175               <para> Regular file truncated</para>
176             </entry>
177           </row>
178           <row>
179             <entry>
180               <para> SATTR</para>
181             </entry>
182             <entry>
183               <para> Attribute change</para>
184             </entry>
185           </row>
186           <row>
187             <entry>
188               <para> XATTR</para>
189             </entry>
190             <entry>
191               <para> Extended attribute change (setxattr)</para>
192             </entry>
193           </row>
194           <row>
195             <entry>
196               <para> HSM</para>
197             </entry>
198             <entry>
199               <para> HSM specific event</para>
200             </entry>
201           </row>
202           <row>
203             <entry>
204               <para> MTIME</para>
205             </entry>
206             <entry>
207               <para> MTIME change</para>
208             </entry>
209           </row>
210           <row>
211             <entry>
212               <para> CTIME</para>
213             </entry>
214             <entry>
215               <para> CTIME change</para>
216             </entry>
217           </row>
218           <row>
219             <entry>
220               <para> ATIME *</para>
221             </entry>
222             <entry>
223               <para> ATIME change</para>
224             </entry>
225           </row>
226           <row>
227             <entry>
228               <para> MIGRT</para>
229             </entry>
230             <entry>
231               <para> Migration event</para>
232             </entry>
233           </row>
234           <row>
235             <entry>
236               <para> FLRW</para>
237             </entry>
238             <entry>
239               <para> File Level Replication: file initially written</para>
240             </entry>
241           </row>
242           <row>
243             <entry>
244               <para> RESYNC</para>
245             </entry>
246             <entry>
247               <para> File Level Replication: file re-synced</para>
248             </entry>
249           </row>
250           <row>
251             <entry>
252               <para> GXATR *</para>
253             </entry>
254             <entry>
255               <para> Extended attribute access (getxattr)</para>
256             </entry>
257           </row>
258           <row>
259             <entry>
260               <para> NOPEN *</para>
261             </entry>
262             <entry>
263               <para> Denied open</para>
264             </entry>
265           </row>
266         </tbody>
267       </tgroup>
268     </informaltable>
269     <note><para>Event types marked with * are not recorded by default. Refer to
270     <xref linkend="dbdoclet.modifyChangelogMask" /> for instructions on
271     modifying the Changelogs mask.</para></note>
272     <para>FID-to-full-pathname and pathname-to-FID functions are also included
273     to map target and parent FIDs into the file system namespace.</para>
274     <section remap="h3">
275       <title><indexterm><primary>monitoring</primary><secondary>change logs
276     </secondary></indexterm>
277 Working with Changelogs</title>
278       <para>Several commands are available to work with changelogs.</para>
279       <section remap="h5">
280         <title>
281           <literal>lctl changelog_register</literal>
282         </title>
283         <para>Because changelog records take up space on the MDT, the system
284         administration must register changelog users. As soon as a changelog
285         user is registered, the Changelogs feature is enabled. The registrants
286         specify which records they are &quot;done with&quot;, and the system
287         purges up to the greatest common record.</para>
288         <para>To register a new changelog user, run:</para>
289         <screen>mds# lctl --device <replaceable>fsname</replaceable>-<replaceable>MDTnumber</replaceable> changelog_register
290 </screen>
291         <para>Changelog entries are not purged beyond a registered user&apos;s
292         set point (see <literal>lfs changelog_clear</literal>).</para>
293       </section>
294       <section remap="h5">
295         <title>
296           <literal>lfs changelog</literal>
297         </title>
298         <para>To display the metadata changes on an MDT (the changelog records),
299         run:</para>
300         <screen>lfs changelog <replaceable>fsname</replaceable>-<replaceable>MDTnumber</replaceable> [startrec [endrec]] </screen>
301         <para>It is optional whether to specify the start and end
302         records.</para>
303         <para>These are sample changelog records:</para>
304         <screen>1 02MKDIR 15:15:21.977666834 2018.01.09 0x0 t=[0x200000402:0x1:0x0] j=mkdir.500 ef=0xf \
305 u=500:500 nid=10.128.11.159@tcp p=[0x200000007:0x1:0x0] pics
306 2 01CREAT 15:15:36.687592024 2018.01.09 0x0 t=[0x200000402:0x2:0x0] j=cp.500 ef=0xf \
307 u=500:500 nid=10.128.11.159@tcp p=[0x200000402:0x1:0x0] chloe.jpg
308 3 06UNLNK 15:15:41.305116815 2018.01.09 0x1 t=[0x200000402:0x2:0x0] j=rm.500 ef=0xf \
309 u=500:500 nid=10.128.11.159@tcp p=[0x200000402:0x1:0x0] chloe.jpg
310 4 07RMDIR 15:15:46.468790091 2018.01.09 0x1 t=[0x200000402:0x1:0x0] j=rmdir.500 ef=0xf \
311 u=500:500 nid=10.128.11.159@tcp p=[0x200000007:0x1:0x0] pics </screen>
312       </section>
313       <section remap="h5">
314         <title>
315           <literal>lfs changelog_clear</literal>
316         </title>
317         <para>To clear old changelog records for a specific user (records that
318         the user no longer needs), run:</para>
319         <screen>lfs changelog_clear <replaceable>mdt_name</replaceable> <replaceable>userid</replaceable> <replaceable>endrec</replaceable></screen>
320         <para>The <literal>changelog_clear</literal> command indicates that
321         changelog records previous to <replaceable>endrec</replaceable> are no
322         longer of interest to a particular user
323         <replaceable>userid</replaceable>, potentially allowing the MDT to free
324         up disk space. An <literal><replaceable>endrec</replaceable></literal>
325         value of 0 indicates the current last record. To run
326         <literal>changelog_clear</literal>, the changelog user must be
327         registered on the MDT node using <literal>lctl</literal>.</para>
328         <para>When all changelog users are done with records &lt; X, the records
329         are deleted.</para>
330       </section>
331       <section remap="h5">
332         <title>
333           <literal>lctl changelog_deregister</literal>
334         </title>
335         <para>To deregister (unregister) a changelog user, run:</para>
336         <screen>mds# lctl --device <replaceable>mdt_device</replaceable> changelog_deregister <replaceable>userid</replaceable>       </screen>
337         <para> <literal>changelog_deregister cl1</literal> effectively does a
338         <literal>lfs changelog_clear cl1 0</literal> as it deregisters.</para>
339       </section>
340     </section>
341     <section remap="h3">
342       <title>Changelog Examples</title>
343       <para>This section provides examples of different changelog
344       commands.</para>
345       <section remap="h5">
346         <title>Registering a Changelog User</title>
347         <para>To register a new changelog user for a device
348         (<literal>lustre-MDT0000</literal>):</para>
349         <screen>mds# lctl --device lustre-MDT0000 changelog_register
350 lustre-MDT0000: Registered changelog userid &apos;cl1&apos;</screen>
351       </section>
352       <section remap="h5">
353         <title>Displaying Changelog Records</title>
354         <para>To display changelog records on an MDT
355         (<literal>lustre-MDT0000</literal>):</para>
356         <screen>$ lfs changelog lustre-MDT0000
357 1 02MKDIR 15:15:21.977666834 2018.01.09 0x0 t=[0x200000402:0x1:0x0] ef=0xf \
358 u=500:500 nid=10.128.11.159@tcp p=[0x200000007:0x1:0x0] pics
359 2 01CREAT 15:15:36.687592024 2018.01.09 0x0 t=[0x200000402:0x2:0x0] ef=0xf \
360 u=500:500 nid=10.128.11.159@tcp p=[0x200000402:0x1:0x0] chloe.jpg
361 3 06UNLNK 15:15:41.305116815 2018.01.09 0x1 t=[0x200000402:0x2:0x0] ef=0xf \
362 u=500:500 nid=10.128.11.159@tcp p=[0x200000402:0x1:0x0] chloe.jpg
363 4 07RMDIR 15:15:46.468790091 2018.01.09 0x1 t=[0x200000402:0x1:0x0] ef=0xf \
364 u=500:500 nid=10.128.11.159@tcp p=[0x200000007:0x1:0x0] pics</screen>
365         <para>Changelog records include this information:</para>
366         <screen>rec# 
367 operation_type(numerical/text) 
368 timestamp 
369 datestamp 
370 flags 
371 t=target_FID 
372 ef=extended_flags
373 u=uid:gid
374 nid=client_NID
375 p=parent_FID 
376 target_name</screen>
377         <para>Displayed in this format:</para>
378         <screen>rec# operation_type(numerical/text) timestamp datestamp flags t=target_FID \
379 ef=extended_flags u=uid:gid nid=client_NID p=parent_FID target_name</screen>
380         <para>For example:</para>
381         <screen>2 01CREAT 15:15:36.687592024 2018.01.09 0x0 t=[0x200000402:0x2:0x0] ef=0xf \
382 u=500:500 nid=10.128.11.159@tcp p=[0x200000402:0x1:0x0] chloe.jpg</screen>
383       </section>
384       <section remap="h5">
385         <title>Clearing Changelog Records</title>
386         <para>To notify a device that a specific user (<literal>cl1</literal>)
387         no longer needs records (up to and including 3):</para>
388         <screen>$ lfs changelog_clear  lustre-MDT0000 cl1 3</screen>
389         <para>To confirm that the <literal>changelog_clear</literal> operation
390         was successful, run <literal>lfs changelog</literal>; only records after
391         id-3 are listed:</para>
392         <screen>$ lfs changelog lustre-MDT0000
393 4 07RMDIR 15:15:46.468790091 2018.01.09 0x1 t=[0x200000402:0x1:0x0] ef=0xf \
394 u=500:500 nid=10.128.11.159@tcp p=[0x200000007:0x1:0x0] pics</screen>
395       </section>
396       <section remap="h5">
397         <title>Deregistering a Changelog User</title>
398         <para>To deregister a changelog user (<literal>cl1</literal>) for a
399         specific device (<literal>lustre-MDT0000</literal>):</para>
400         <screen>mds# lctl --device lustre-MDT0000 changelog_deregister cl1
401 lustre-MDT0000: Deregistered changelog user &apos;cl1&apos;</screen>
402         <para>The deregistration operation clears all changelog records for the
403         specified user (<literal>cl1</literal>).</para>
404         <screen>$ lfs changelog lustre-MDT0000
405 5 00MARK  15:56:39.603643887 2018.01.09 0x0 t=[0x20001:0x0:0x0] ef=0xf \
406 u=500:500 nid=0@&lt;0:0&gt; p=[0:0x50:0xb] mdd_obd-lustre-MDT0000-0
407 </screen>
408         <note>
409           <para>MARK records typically indicate changelog recording status
410           changes.</para>
411         </note>
412       </section>
413       <section remap="h5">
414         <title>Displaying the Changelog Index and Registered Users</title>
415         <para>To display the current, maximum changelog index and registered
416         changelog users for a specific device
417         (<literal>lustre-MDT0000</literal>):</para>
418         <screen>mds# lctl get_param  mdd.lustre-MDT0000.changelog_users 
419 mdd.lustre-MDT0000.changelog_users=current index: 8 
420 ID    index (idle seconds)
421 cl2   8 (180)
422 </screen>
423       </section>
424       <section remap="h5">
425         <title>Displaying the Changelog Mask</title>
426         <para>To show the current changelog mask on a specific device
427         (<literal>lustre-MDT0000</literal>):</para>
428         <screen>mds# lctl get_param  mdd.lustre-MDT0000.changelog_mask 
429
430 mdd.lustre-MDT0000.changelog_mask= 
431 MARK CREAT MKDIR HLINK SLINK MKNOD UNLNK RMDIR RENME RNMTO CLOSE LYOUT \
432 TRUNC SATTR XATTR HSM MTIME CTIME MIGRT
433 </screen>
434       </section>
435       <section xml:id="dbdoclet.modifyChangelogMask" remap="h5">
436         <title>Setting the Changelog Mask</title>
437         <para>To set the current changelog mask on a specific device
438         (<literal>lustre-MDT0000</literal>):</para>
439         <screen>mds# lctl set_param mdd.lustre-MDT0000.changelog_mask=HLINK 
440 mdd.lustre-MDT0000.changelog_mask=HLINK 
441 $ lfs changelog_clear lustre-MDT0000 cl1 0 
442 $ mkdir /mnt/lustre/mydir/foo
443 $ cp /etc/hosts /mnt/lustre/mydir/foo/file
444 $ ln /mnt/lustre/mydir/foo/file /mnt/lustre/mydir/myhardlink
445 </screen>
446         <para>Only item types that are in the mask show up in the
447         changelog.</para>
448         <screen>$ lfs changelog lustre-MDT0000
449 9 03HLINK 16:06:35.291636498 2018.01.09 0x0 t=[0x200000402:0x4:0x0] ef=0xf \
450 u=500:500 nid=10.128.11.159@tcp p=[0x200000007:0x3:0x0] myhardlink
451 </screen>
452         <para></para>
453       </section>
454     </section>
455     <section remap="h3" condition='l2B'>
456       <title><indexterm><primary>audit</primary>
457       <secondary>change logs</secondary></indexterm>
458 Audit with Changelogs</title>
459       <para>A specific use case for Lustre Changelogs is audit. According to a
460       definition found on <link xmlns:xlink="http://www.w3.org/1999/xlink"
461       xlink:href="https://en.wikipedia.org/wiki/Information_technology_audit">
462       Wikipedia</link>, information technology audits are used to evaluate the
463       organization's ability to protect its information assets and to properly
464       dispense information to authorized parties. Basically, audit consists in
465       controlling that all data accesses made were done according to the access
466       control policy in place. And usually, this is done by analyzing access
467       logs.</para>
468       <para>Audit can be used as a proof of security in place. But Audit can
469       also be a requirement to comply with regulations.</para>
470       <para>Lustre Changelogs are a good mechanism for audit, because this is a
471       centralized facility, and it is designed to be transactional. Changelog
472       records contain all information necessary for auditing purposes:</para>
473       <itemizedlist>
474         <listitem>
475           <para>ability to identify object of action thanks to file identifiers
476           (FIDs) and name of targets</para>
477         </listitem>
478         <listitem>
479           <para>ability to identify subject of action thanks to UID/GID and NID
480           information</para>
481         </listitem>
482         <listitem>
483           <para>ability to identify time of action thanks to timestamp</para>
484         </listitem>
485       </itemizedlist>
486       <section remap="h5">
487         <title>Enabling Audit</title>
488         <para>To have a fully functional Changelogs-based audit facility, some
489         additional Changelog record types must be enabled, to be able to record
490         events such as OPEN, ATIME, GETXATTR and DENIED OPEN. Please note that
491         enabling these record types may have some performance impact. For
492         instance, recording OPEN and GETXATTR events generate writes in the
493         Changelog records for a read operation from a file-system
494         standpoint.</para>
495         <para>Being able to record events such as OPEN or DENIED OPEN is
496         important from an audit perspective. For instance, if Lustre file system
497         is used to store medical records on a system dedicated to Life Sciences,
498         data privacy is crucial. Administrators may need to know which doctors
499         accessed, or tried to access, a given medical record and when. And
500         conversely, they might need to know which medical records a given doctor
501         accessed.</para>
502         <para>To enable all changelog entry types, do:</para>
503         <screen>mds# lctl set_param mdd.lustre-MDT0000.changelog_mask=ALL
504 mdd.seb-MDT0000.changelog_mask=ALL</screen>
505         <para>Once all required record types have been enabled, just register a
506         Changelogs user and the audit facility is operational.</para>
507         <para>Note that, however, it is possible to control which Lustre client
508         nodes can trigger the recording of file system access events to the
509         Changelogs, thanks to the <literal>audit_mode</literal> flag on nodemap
510         entries. The reason to disable audit on a per-nodemap basis is to
511         prevent some nodes (e.g. backup, HSM agent nodes) from flooding the
512         audit logs. When <literal>audit_mode</literal> flag is
513         set to 1 on a nodemap entry, a client pertaining to this nodemap will be
514         able to record file system access events to the Changelogs, if
515         Changelogs are otherwise activated. When set to 0, events are not logged
516         into the Changelogs, no matter if Changelogs are activated or not. By
517         default, <literal>audit_mode</literal> flag is set to 1 in newly created
518         nodemap entries. And it is also set to 1 in 'default' nodemap.</para>
519         <para>To prevent nodes pertaining to a nodemap to generate Changelog
520         entries, do:</para>
521         <screen>
522 mgs# lctl nodemap_modify --name nm1 --property audit_mode --value 0</screen>
523       </section>
524       <section remap="h5">
525         <title>Audit examples</title>
526         <section remap="h5">
527           <title>
528             <literal>OPEN</literal>
529           </title>
530           <para>An OPEN changelog entry is in the form:</para>
531           <screen>
532 7 10OPEN  13:38:51.510728296 2017.07.25 0x242 t=[0x200000401:0x2:0x0] \
533 ef=0x7 u=500:500 nid=10.128.11.159@tcp m=-w-</screen>
534           <para>It includes information about the open mode, in the form
535           m=rwx.</para>
536           <para>OPEN entries are recorded only once per UID/GID, for a given
537           open mode, as long as the file is not closed by this UID/GID. It
538           avoids flooding the Changelogs for instance if there is an MPI job
539           opening the same file thousands of times from different threads. It
540           reduces the ChangeLog load significantly, without significantly
541           affecting the audit information. Similarly, only the last CLOSE per
542           UID/GID is recorded.</para>
543         </section>
544         <section remap="h5">
545           <title>
546             <literal>GETXATTR</literal>
547           </title>
548           <para>A GETXATTR changelog entry is in the form:</para>
549           <screen>
550 8 23GXATR 09:22:55.886793012 2017.07.27 0x0 t=[0x200000402:0x1:0x0] \
551 ef=0xf u=500:500 nid=10.128.11.159@tcp x=user.name0</screen>
552           <para>It includes information about the name of the extended attribute
553           being accessed, in the form <literal>x=&lt;xattr name&gt;</literal>.
554           </para>
555         </section>
556         <section remap="h5">
557           <title>
558             <literal>SETXATTR</literal>
559           </title>
560           <para>A SETXATTR changelog entry is in the form:</para>
561           <screen>
562 4 15XATTR 09:41:36.157333594 2018.01.10 0x0 t=[0x200000402:0x1:0x0] \
563 ef=0xf u=500:500 nid=10.128.11.159@tcp x=user.name0</screen>
564           <para>It includes information about the name of the extended attribute
565           being modified, in the form <literal>x=&lt;xattr name&gt;</literal>.
566           </para>
567         </section>
568         <section remap="h5">
569           <title>
570             <literal>DENIED OPEN</literal>
571           </title>
572           <para>A DENIED OPEN changelog entry is in the form:</para>
573           <screen>
574 4 24NOPEN 15:45:44.947406626 2017.08.31 0x2 t=[0x200000402:0x1:0x0] \
575 ef=0xf u=500:500 nid=10.128.11.158@tcp m=-w-</screen>
576           <para>It has the same information as a regular OPEN entry. In order to
577           avoid flooding the Changelogs, DENIED OPEN entries are rate limited:
578           no more than one entry per user per file per time interval, this time
579           interval (in seconds) being configurable via
580           <literal>mdd.&lt;mdtname&gt;.changelog_deniednext</literal>
581           (default value is 60 seconds).</para>
582           <screen>
583 mds# lctl set_param mdd.lustre-MDT0000.changelog_deniednext=120
584 mdd.seb-MDT0000.changelog_deniednext=120
585 mds# lctl get_param mdd.lustre-MDT0000.changelog_deniednext
586 mdd.seb-MDT0000.changelog_deniednext=120</screen>
587         </section>
588       </section>
589     </section>
590   </section>
591   <section xml:id="dbdoclet.jobstats">
592       <title><indexterm><primary>jobstats</primary><see>monitoring</see></indexterm>
593 <indexterm><primary>monitoring</primary></indexterm>
594 <indexterm><primary>monitoring</primary><secondary>jobstats</secondary></indexterm>
595
596 Lustre Jobstats</title>
597     <para>The Lustre jobstats feature is available starting in Lustre software
598     release 2.3. It collects file system operation statistics for user processes
599     running on Lustre clients, and exposes them via procfs on the server using
600     the unique Job Identifier (JobID) provided by the job scheduler for each
601     job. Job schedulers known to be able to work with jobstats include:
602       SLURM, SGE, LSF, Loadleveler, PBS and Maui/MOAB.</para>
603     <para>Since jobstats is implemented in a scheduler-agnostic manner, it is
604     likely that it will be able to work with other schedulers also.</para>
605     <section remap="h3">
606       <title><indexterm><primary>monitoring</primary><secondary>jobstats</secondary></indexterm>
607       How Jobstats Works</title>
608       <para>The Lustre jobstats code on the client extracts the unique JobID
609       from an environment variable within the user process, and sends this
610       JobID to the server with the I/O operation.  The server tracks
611       statistics for operations whose JobID is given, indexed by that
612       ID.</para>
613       
614       <para>A Lustre setting on the client, <literal>jobid_var</literal>,
615       specifies which variable to use.  Any environment variable can be
616       specified.  For example, SLURM sets the
617       <literal>SLURM_JOB_ID</literal> environment variable with the unique
618       job ID on each client when the job is first launched on a node, and
619       the <literal>SLURM_JOB_ID</literal> will be inherited by all child
620       processes started below that process.</para>
621       
622       <para>Lustre can also be configured to generate a synthetic JobID from
623       the user's process name and User ID, by setting
624       <literal>jobid_var</literal> to a special value,
625       <literal>procname_uid</literal>.</para>
626       
627       <para>The setting of <literal>jobid_var</literal> need not be the same
628       on all clients.  For example, one could use
629       <literal>SLURM_JOB_ID</literal> on all clients managed by SLURM, and
630       use <literal>procname_uid</literal> on clients not managed by SLURM,
631       such as interactive login nodes.</para>
632       
633       <para>It is not possible to have different
634       <literal>jobid_var</literal> settings on a single node, since it is
635       unlikely that multiple job schedulers are active on one client.
636       However, the actual JobID value is local to each process environment
637       and it is possible for multiple jobs with different JobIDs to be
638       active on a single client at one time.</para>
639     </section>
640
641     <section remap="h3">
642       <title><indexterm><primary>monitoring</primary><secondary>jobstats</secondary></indexterm>
643 Enable/Disable Jobstats</title>
644       <para>Jobstats are disabled by default.  The current state of jobstats
645       can be verified by checking <literal>lctl get_param jobid_var</literal>
646       on a client:</para>
647       <screen>
648 $ lctl get_param jobid_var
649 jobid_var=disable
650       </screen>
651       <para>
652       To enable jobstats on the <literal>testfs</literal> file system with SLURM:</para>
653       <screen># lctl conf_param testfs.sys.jobid_var=SLURM_JOB_ID</screen>
654       <para>The <literal>lctl conf_param</literal> command to enable or disable
655       jobstats should be run on the MGS as root. The change is persistent, and
656       will be propagated to the MDS, OSS, and client nodes automatically when
657       it is set on the MGS and for each new client mount.</para>
658       <para>To temporarily enable jobstats on a client, or to use a different
659       jobid_var on a subset of nodes, such as nodes in a remote cluster that
660       use a different job scheduler, or interactive login nodes that do not
661       use a job scheduler at all, run the <literal>lctl set_param</literal>
662       command directly on the client node(s) after the filesystem is mounted.
663       For example, to enable the <literal>procname_uid</literal> synthetic
664       JobID on a login node run:
665       <screen># lctl set_param jobid_var=procname_uid</screen>
666       The <literal>lctl set_param</literal> setting is not persistent, and will
667       be reset if the global <literal>jobid_var</literal> is set on the MGS or
668       if the filesystem is unmounted.</para>
669       <para>The following table shows the environment variables which are set
670       by various job schedulers.  Set <literal>jobid_var</literal> to the value
671       for your job scheduler to collect statistics on a per job basis.</para>
672     <informaltable frame="all">
673       <tgroup cols="2">
674         <colspec colname="c1" colwidth="50*"/>
675         <colspec colname="c2" colwidth="50*"/>
676         <thead>
677           <row>
678             <entry>
679               <para><emphasis role="bold">Job Scheduler</emphasis></para>
680             </entry>
681             <entry>
682               <para><emphasis role="bold">Environment Variable</emphasis></para>
683             </entry>
684           </row>
685         </thead>
686         <tbody>
687           <row>
688             <entry>
689               <para>Simple Linux Utility for Resource Management (SLURM)</para>
690             </entry>
691             <entry>
692               <para>SLURM_JOB_ID</para>
693             </entry>
694           </row>
695           <row>
696             <entry>
697               <para>Sun Grid Engine (SGE)</para>
698             </entry>
699             <entry>
700               <para>JOB_ID</para>
701             </entry>
702           </row>
703           <row>
704             <entry>
705               <para>Load Sharing Facility (LSF)</para>
706             </entry>
707             <entry>
708               <para>LSB_JOBID</para>
709             </entry>
710           </row>
711           <row>
712             <entry>
713               <para>Loadleveler</para>
714             </entry>
715             <entry>
716               <para>LOADL_STEP_ID</para>
717             </entry>
718           </row>
719           <row>
720             <entry>
721               <para>Portable Batch Scheduler (PBS)/MAUI</para>
722             </entry>
723             <entry>
724               <para>PBS_JOBID</para>
725             </entry>
726           </row>
727           <row>
728             <entry>
729               <para>Cray Application Level Placement Scheduler (ALPS)</para>
730             </entry>
731             <entry>
732               <para>ALPS_APP_ID</para>
733             </entry>
734           </row>
735         </tbody>
736       </tgroup>
737     </informaltable>
738     <para>There are two special values for <literal>jobid_var</literal>:
739     <literal>disable</literal> and <literal>procname_uid</literal>. To disable
740     jobstats, specify <literal>jobid_var</literal> as <literal>disable</literal>:</para>
741     <screen># lctl conf_param testfs.sys.jobid_var=disable</screen>
742     <para>To track job stats per process name and user ID (for debugging, or
743     if no job scheduler is in use on some nodes such as login nodes), specify
744     <literal>jobid_var</literal> as <literal>procname_uid</literal>:</para>
745     <screen># lctl conf_param testfs.sys.jobid_var=procname_uid</screen>
746     </section>
747     <section remap="h3">
748       <title><indexterm><primary>monitoring</primary><secondary>jobstats</secondary></indexterm>
749 Check Job Stats</title>
750     <para>Metadata operation statistics are collected on MDTs. These statistics can be accessed for
751         all file systems and all jobs on the MDT via the <literal>lctl get_param
752           mdt.*.job_stats</literal>. For example, clients running with
753           <literal>jobid_var=procname_uid</literal>:</para>
754     <screen>
755 # lctl get_param mdt.*.job_stats
756 job_stats:
757 - job_id:          bash.0
758   snapshot_time:   1352084992
759   open:            { samples:     2, unit:  reqs }
760   close:           { samples:     2, unit:  reqs }
761   mknod:           { samples:     0, unit:  reqs }
762   link:            { samples:     0, unit:  reqs }
763   unlink:          { samples:     0, unit:  reqs }
764   mkdir:           { samples:     0, unit:  reqs }
765   rmdir:           { samples:     0, unit:  reqs }
766   rename:          { samples:     0, unit:  reqs }
767   getattr:         { samples:     3, unit:  reqs }
768   setattr:         { samples:     0, unit:  reqs }
769   getxattr:        { samples:     0, unit:  reqs }
770   setxattr:        { samples:     0, unit:  reqs }
771   statfs:          { samples:     0, unit:  reqs }
772   sync:            { samples:     0, unit:  reqs }
773   samedir_rename:  { samples:     0, unit:  reqs }
774   crossdir_rename: { samples:     0, unit:  reqs }
775 - job_id:          mythbackend.0
776   snapshot_time:   1352084996
777   open:            { samples:    72, unit:  reqs }
778   close:           { samples:    73, unit:  reqs }
779   mknod:           { samples:     0, unit:  reqs }
780   link:            { samples:     0, unit:  reqs }
781   unlink:          { samples:    22, unit:  reqs }
782   mkdir:           { samples:     0, unit:  reqs }
783   rmdir:           { samples:     0, unit:  reqs }
784   rename:          { samples:     0, unit:  reqs }
785   getattr:         { samples:   778, unit:  reqs }
786   setattr:         { samples:    22, unit:  reqs }
787   getxattr:        { samples:     0, unit:  reqs }
788   setxattr:        { samples:     0, unit:  reqs }
789   statfs:          { samples: 19840, unit:  reqs }
790   sync:            { samples: 33190, unit:  reqs }
791   samedir_rename:  { samples:     0, unit:  reqs }
792   crossdir_rename: { samples:     0, unit:  reqs }
793     </screen>
794     <para>Data operation statistics are collected on OSTs. Data operations
795     statistics can be accessed via
796     <literal>lctl get_param obdfilter.*.job_stats</literal>, for example:</para>
797     <screen>
798 $ lctl get_param obdfilter.*.job_stats
799 obdfilter.myth-OST0000.job_stats=
800 job_stats:
801 - job_id:          mythcommflag.0
802   snapshot_time:   1429714922
803   read:    { samples: 974, unit: bytes, min: 4096, max: 1048576, sum: 91530035 }
804   write:   { samples:   0, unit: bytes, min:    0, max:       0, sum:        0 }
805   setattr: { samples:   0, unit:  reqs }
806   punch:   { samples:   0, unit:  reqs }
807   sync:    { samples:   0, unit:  reqs }
808 obdfilter.myth-OST0001.job_stats=
809 job_stats:
810 - job_id:          mythbackend.0
811   snapshot_time:   1429715270
812   read:    { samples:   0, unit: bytes, min:     0, max:      0, sum:        0 }
813   write:   { samples:   1, unit: bytes, min: 96899, max:  96899, sum:    96899 }
814   setattr: { samples:   0, unit:  reqs }
815   punch:   { samples:   1, unit:  reqs }
816   sync:    { samples:   0, unit:  reqs }
817 obdfilter.myth-OST0002.job_stats=job_stats:
818 obdfilter.myth-OST0003.job_stats=job_stats:
819 obdfilter.myth-OST0004.job_stats=
820 job_stats:
821 - job_id:          mythfrontend.500
822   snapshot_time:   1429692083
823   read:    { samples:   9, unit: bytes, min: 16384, max: 1048576, sum: 4444160 }
824   write:   { samples:   0, unit: bytes, min:     0, max:       0, sum:       0 }
825   setattr: { samples:   0, unit:  reqs }
826   punch:   { samples:   0, unit:  reqs }
827   sync:    { samples:   0, unit:  reqs }
828 - job_id:          mythbackend.500
829   snapshot_time:   1429692129
830   read:    { samples:   0, unit: bytes, min:     0, max:       0, sum:       0 }
831   write:   { samples:   1, unit: bytes, min: 56231, max:   56231, sum:   56231 }
832   setattr: { samples:   0, unit:  reqs }
833   punch:   { samples:   1, unit:  reqs }
834   sync:    { samples:   0, unit:  reqs }
835     </screen>
836     </section>
837     <section remap="h3">
838       <title><indexterm><primary>monitoring</primary><secondary>jobstats</secondary></indexterm>
839 Clear Job Stats</title>
840     <para>Accumulated job statistics can be reset by writing proc file <literal>job_stats</literal>.</para>
841     <para>Clear statistics for all jobs on the local node:</para>
842     <screen># lctl set_param obdfilter.*.job_stats=clear</screen>
843     <para>Clear statistics only for job 'bash.0' on lustre-MDT0000:</para>
844     <screen># lctl set_param mdt.lustre-MDT0000.job_stats=bash.0</screen>
845     </section>
846     <section remap="h3">
847       <title><indexterm><primary>monitoring</primary><secondary>jobstats</secondary></indexterm>
848 Configure Auto-cleanup Interval</title>
849     <para>By default, if a job is inactive for 600 seconds (10 minutes) statistics for this job will be dropped. This expiration value can be changed temporarily via:</para>
850     <screen># lctl set_param *.*.job_cleanup_interval={max_age}</screen>
851     <para>It can also be changed permanently, for example to 700 seconds via:</para>
852     <screen># lctl conf_param testfs.mdt.job_cleanup_interval=700</screen>
853     <para>The <literal>job_cleanup_interval</literal> can be set as 0 to disable the auto-cleanup. Note that if auto-cleanup of Jobstats is disabled, then all statistics will be kept in memory forever, which may eventually consume all memory on the servers. In this case, any monitoring tool should explicitly clear individual job statistics as they are processed, as shown above.</para>
854     </section>
855   </section>
856   <section xml:id="dbdoclet.50438273_81684">
857     <title><indexterm>
858         <primary>monitoring</primary>
859         <secondary>Lustre Monitoring Tool</secondary>
860       </indexterm> Lustre Monitoring Tool (LMT)</title>
861     <para>The Lustre Monitoring Tool (LMT) is a Python-based, distributed system that provides a
862         <literal>top</literal>-like display of activity on server-side nodes (MDS, OSS and portals
863       routers) on one or more Lustre file systems. It does not provide support for monitoring
864       clients. For more information on LMT, including the setup procedure, see:</para>
865     <para><link xl:href="http://code.google.com/p/lmt/"
866       >https://github.com/chaos/lmt/wiki</link></para>
867     <para>LMT questions can be directed to:</para>
868     <para><link xl:href="mailto:lmt-discuss@googlegroups.com">lmt-discuss@googlegroups.com</link></para>
869   </section>
870   <section xml:id="dbdoclet.50438273_80593">
871     <title>
872       <literal>CollectL</literal>
873     </title>
874     <para><literal>CollectL</literal> is another tool that can be used to monitor a Lustre file
875       system. You can run <literal>CollectL</literal> on a Lustre system that has any combination of
876       MDSs, OSTs and clients. The collected data can be written to a file for continuous logging and
877       played back at a later time. It can also be converted to a format suitable for
878       plotting.</para>
879     <para>For more information about <literal>CollectL</literal>, see:</para>
880     <para><link xl:href="http://collectl.sourceforge.net">http://collectl.sourceforge.net</link></para>
881     <para>Lustre-specific documentation is also available. See:</para>
882     <para><link xl:href="http://collectl.sourceforge.net/Tutorial-Lustre.html">http://collectl.sourceforge.net/Tutorial-Lustre.html</link></para>
883   </section>
884   <section xml:id="dbdoclet.50438273_44185">
885     <title><indexterm><primary>monitoring</primary><secondary>additional tools</secondary></indexterm>
886 Other Monitoring Options</title>
887     <para>A variety of standard tools are available publicly including the following:<itemizedlist>
888         <listitem>
889           <para><literal>lltop</literal> - Lustre load monitor with batch scheduler integration.
890               <link xmlns:xlink="http://www.w3.org/1999/xlink"
891               xlink:href="https://github.com/jhammond/lltop"
892               >https://github.com/jhammond/lltop</link></para>
893         </listitem>
894         <listitem>
895           <para><literal>tacc_stats</literal> - A job-oriented system monitor, analyzation, and
896             visualization tool that probes Lustre interfaces and collects statistics. <link
897               xmlns:xlink="http://www.w3.org/1999/xlink"
898               xlink:href="https://github.com/jhammond/tacc_stats"/></para>
899         </listitem>
900         <listitem>
901           <para><literal>xltop</literal> - A continuous Lustre monitor with batch scheduler
902             integration. <link xmlns:xlink="http://www.w3.org/1999/xlink"
903               xlink:href="https://github.com/jhammond/xltop"/></para>
904         </listitem>
905       </itemizedlist></para>
906     <para>Another option is to script a simple monitoring solution that looks at various reports
907       from <literal>ipconfig</literal>, as well as the <literal>procfs</literal> files generated by
908       the Lustre software.</para>
909   </section>
910 </chapter>