ورود به سیستم: چه، چگونه، کجا و با چه چیزی؟

سلام به همه اعضای انجمن CodeGym! امروز بیایید در مورد ورود به سیستم صحبت کنیم:

1. چیست، چرا وجود دارد، چه زمانی باید از آن استفاده کنید، چه زمانی باید از آن اجتناب کنید.
2. چه پیاده سازی های ورود به سیستم در جاوا موجود است، و چه کاری باید با همه این گزینه های ورود به سیستم انجام دهید.
و سطوح ورود به سیستم. ما بحث خواهیم کرد که appender چیست و چگونه آن را به درستی پیکربندی کنیم.
3. ثبت گره ها و نحوه پیکربندی صحیح آنها به طوری که همه چیز همانطور که می خواهیم کار کند.

این مطالب برای مخاطبان گسترده در نظر گرفته شده است. برای هر کسی که به تازگی با جاوا آشنا می شود و همچنین افرادی که در حال حاضر مشغول به کار هستند اما فقط logger.info("log something"); Let's Go را کاوش کرده اند، واضح خواهد بود!

چرا به ورود به سیستم نیاز دارید؟

بیایید به چند مورد واقعی نگاه کنیم که در آن ورود به سیستم می تواند یک مشکل را حل کند. در اینجا یک نمونه از کار من است. نقاطی وجود دارد که یک برنامه کاربردی با سرویس های دیگر ادغام می شود. من از ورود به سیستم در این نقاط برای ایجاد نوعی "علیه" استفاده می کنم: اگر ادغام کار نمی کند، تشخیص اینکه کدام طرف مشکل دارد آسان می شود. همچنین ثبت اطلاعات مهم ذخیره شده در پایگاه داده مطلوب است. به عنوان مثال، ایجاد یک کاربر ادمین. این دقیقاً همان چیزی است که ورود به سیستم خوب است.

ابزارهایی برای ورود به جاوا

در میان راه حل های شناخته شده لاگ در جاوا، می توان موارد زیر را برجسته کرد:

• Log4j
• JUL - java.util.logging
• JCL - ورود به سیستم جاکارتا کامانز
• ورود به سیستم
• SLF4J - نمای ورود ساده برای جاوا

System.err.println

در ابتدا، System.err.println (نمایش ورودی های گزارش روی کنسول) وجود داشت. حتی امروزه نیز از این تکنیک برای ثبت سریع گزارش هنگام اشکال زدایی استفاده می شود. البته تنظیماتی برای بحث در اینجا وجود ندارد، بنابراین فقط این روش را به خاطر بسپارید و به ادامه می‌رویم.

Log4j

این یک راه حل کامل است که توسعه دهندگان از سر ناچاری ایجاد کرده اند. نتیجه یک ابزار واقعا جالب است که می توانید از آن استفاده کنید. به دلیل شرایط مختلف، این راه حل به JDK ختم نشد، واقعیتی که به شدت کل جامعه را ناراحت کرد. Log4j دارای گزینه های پیکربندی است که به شما امکان می دهد ورود به com.example.typeبسته را فعال کرده و آن را در بسته فرعی خاموش کنید com.example.type.generic. این امکان حذف سریع کدهایی را فراهم می کند که نیازی به ثبت نام ندارند. در اینجا ذکر این نکته ضروری است که دو نسخه Log4j وجود دارد: 1.2.x و 2.xx، و آنها با یکدیگر ناسازگار هستند . Log4j مفاهیم appender (ابزاری که برای نوشتن گزارش استفاده می شود) و طرح بندی (قالب بندی log) را اضافه کرد. این به شما امکان می دهد فقط آنچه را که نیاز دارید وارد کنید و همانطور که نیاز دارید آن را ثبت کنید. کمی بعد در مورد appender بیشتر صحبت خواهیم کرد.

JUL - java.util.logging

یکی از مزایای کلیدی این راه حل این است که JUL در JDK (کیت توسعه جاوا) گنجانده شده است. متأسفانه، زمانی که آن را توسعه داد، سازندگان آن را بر اساس ابزار محبوب Log4j قرار ندادند، بلکه راه حلی از IBM بود. آن تصمیم عواقبی داشته است. واقعیت این است که در حال حاضر هیچ کس از JUL استفاده نمی کند. سطوح گزارش در JUL با آنچه Logback، Log4j و Slf4j دارند متفاوت است. این موضوع درک یکدیگر را برای آنها دشوارتر می کند. ایجاد یک لاگر کم و بیش مشابه است. برای انجام این کار، باید یک import انجام دهید:

java.util.logging.Logger log = java.util.logging.Logger.getLogger(LoggingJul.class.getName());

نام کلاس ارسال شده است، بنابراین ما می دانیم که ورود ما از کجا خواهد آمد. با شروع با جاوا 8، می توانید بگذرید Supplier<String>. این به ما کمک می‌کند که یک خط را فقط زمانی که واقعاً به آن نیاز داریم بخوانیم و بسازیم، نه هر بار، همانطور که قبلاً چنین بود. تنها با انتشار جاوا 8، توسعه دهندگان در نهایت مشکلات مهم را حل کردند و JUL را واقعاً قابل استفاده کردند. یعنی متدهایی با Supplier<String> msgSupplierپارامتری که در زیر نشان داده شده است:

public void info(Supplier<String> msgSupplier) {
   log(Level.INFO, msgSupplier);
}

JCL - ورود به سیستم جاکارتا کامانز

از آنجایی که برای مدت طولانی هیچ استاندارد صنعتی در مورد ورود به سیستم وجود نداشت و بسیاری از افراد لاگرهای سفارشی خود را ایجاد کردند، تصمیم به انتشار JCL گرفته شد، یک لفاف عمومی که می‌توان آن را در بالای دیگران استفاده کرد. چرا؟ گاهی اوقات وابستگی هایی که به پروژه اضافه می شوند از لاگر متفاوتی نسبت به آنچه در پروژه است استفاده می کنند. به همین دلیل، آنها به عنوان وابستگی های گذرا به پروژه اضافه شدند و این باعث ایجاد مشکلات واقعی در هنگام تلاش برای کنار هم قرار دادن آن ها شد. متأسفانه لفاف خیلی کاربردی نبود و چیزی اضافه نکرد. اگر همه از JCL استفاده کنند، احتمالاً راحت خواهد بود. اما این چیزی نیست که اتفاق افتاده است، بنابراین استفاده از JCL بهترین ایده در حال حاضر نیست.

ورود به سیستم

مسیر منبع باز خاردار است... همان توسعه دهنده ای که Log4j را نوشت، Logback را نیز به عنوان یک چارچوب لاگ جانشین نوشت. این بر اساس همان ایده Log4j بود. تفاوت های Logback عبارتند از:

• عملکرد بهبود یافته
• پشتیبانی بومی برای Slf4j اضافه شده است
• گزینه های فیلتر گسترده

به طور پیش فرض، Logback نیازی به پیکربندی ندارد و همه رویدادها را در سطح DEBUG و بالاتر ثبت می کند. اگر نیاز به سفارشی سازی دارید، می توانید از طریق یک پیکربندی XML به آن دست پیدا کنید:

<configuration>
    <appender name="FILE" class="ch.qos.logback.core.FileAppender">
        <file>app.log</file>
        <encoder>
            <pattern>%d{HH:mm:ss,SSS} %-5p [%c] - %m%n</pattern>
        </encoder>
    </appender>
    <logger name="org.hibernate.SQL" level="DEBUG" />
    <logger name="org.hibernate.type.descriptor.sql" level="TRACE" />
    <root level="info">
        <appender-ref ref="FILE" />
    </root>
</configuration>

SLF4J - نمای ورود ساده برای جاوا

زمانی در سال 2006، یکی از بنیانگذاران Log4j پروژه را ترک کرد و Slf4j (نمای ورود ساده برای جاوا) را ایجاد کرد، یک پوشش برای Log4j، JUL، Common-logging و Logback. همانطور که می بینید، ما تا مرحله ایجاد یک wrapper روی یک wrapper پیشرفت کرده ایم ... در این مورد، به دو بخش تقسیم می شود: API که در برنامه استفاده می شود و پیاده سازی که با جداگانه اضافه می شود. وابستگی برای هر نوع ورود به سیستم. به عنوان مثال، slf4j-log4j12.jarو slf4j-jdk14.jar. شما باید پیاده سازی صحیح را متصل کنید و تمام: کل پروژه شما از آن استفاده خواهد کرد. Slf4j از آخرین ویژگی‌ها مانند قالب‌بندی رشته‌ها برای ورود به سیستم پشتیبانی می‌کند. قبلا چنین مشکلی وجود داشت. بیایید بگوییم که یک ورودی گزارش مانند این ایجاد می کنیم:

log.debug("User " + user + " connected from " + request.getRemoteAddr());

با توجه به عملگر الحاق، userجسم به لطف وجود بی‌صدا به یک رشته تبدیل می‌شود user.toString(). این زمان می برد و سرعت سیستم را کاهش می دهد. و اگر برنامه را اشکال زدایی کنیم ممکن است خوب باشد. اگر سطح گزارش برای این کلاس INFO یا بالاتر باشد، با مشکلاتی مواجه می شویم. به عبارت دیگر، ما نباید این ورودی گزارش را بنویسیم (برای اطلاعات یا بالاتر)، و نباید از الحاق رشته استفاده کنیم. در تئوری، خود کتابخانه ورود به سیستم باید به این موضوع بپردازد. همانطور که اتفاق می افتد، این بزرگترین مشکل در نسخه اول Log4j بود. راه حل مناسبی ارائه نکرد، اما در عوض پیشنهاد انجام کاری شبیه به این را داد:

if (log.isDebugEnabled()) {
    log.debug("User " + user + " connected from " + request.getRemoteAddr());
}

یعنی به جای یک خط کد برای لاگ، نوشتن 3 را پیشنهاد کردند! ورود به سیستم باید تغییرات کد را به حداقل برساند و این سه خط به وضوح این رویکرد کلی را نقض می کند. Slf4j هیچ مشکل سازگاری با JDK و API نداشت، بنابراین بلافاصله یک راه حل خوب ظاهر شد:

log.debug("User {} connected from {}", user, request.getRemoteAddr());

جایی که {}نشان دهنده مکان نگهدارنده برای آرگومان های ارسال شده به متد است. یعنی اولی {}مربوط به user, و دومی {}مطابق با request.getRemoteAddr(). با انجام این کار، الحاق رشته ها را تنها در صورتی انجام می دهیم که سطح log از ما بخواهد که ورودی log را بنویسیم. پس از آن، Sjf4j شروع به رشد سریع در محبوبیت کرد. در حال حاضر بهترین راه حل است. بر این اساس، بیایید نگاهی به ورود به سیستم با استفاده از یک slf4j-log4j12اتصال بیاندازیم.

آنچه باید ثبت شود

البته، شما نباید همه چیز را وارد کنید. این اغلب ضروری نیست و گاهی اوقات حتی خطرناک است. به عنوان مثال، اگر شما اطلاعات شخصی شخصی را ثبت کنید و به نحوی به بیرون درز کند، مشکلات واقعی به خصوص در پروژه های متمرکز بر بازارهای غربی وجود خواهد داشت. اما مواردی نیز وجود دارد که باید حتماً آنها را وارد کنید :

1. شروع/پایان برنامه ما باید بدانیم که آیا برنامه واقعاً همانطور که انتظار می رفت شروع و به پایان رسید یا خیر.
2. مسائل امنیتی. در اینجا خوب است که تلاش‌ها برای حدس زدن رمز عبور افراد، مواردی که هنگام ورود مدیران به سیستم وارد می‌شوند و غیره ثبت شوند.
3. برخی از حالات کاربردی به عنوان مثال، انتقال از یک حالت به حالت دیگر در یک فرآیند تجاری.
4. برخی از اطلاعات اشکال زدایی به همراه سطح گزارش مربوطه.
5. اسکریپت های خاص SQL مواردی در دنیای واقعی وجود دارد که این امر ضروری است. اما باز هم، با تنظیم ماهرانه سطوح لاگ، می توانید به نتایج عالی دست پیدا کنید.
6. هنگام تأیید اینکه کارها به درستی کار می کنند، می توان رشته های در حال اجرا را ثبت کرد.

خطاهای رایج در ورود به سیستم

در اینجا تفاوت های ظریف زیادی وجود دارد، اما ما به چند اشتباه رایج اشاره می کنیم:

1. قطع بیش از حد. شما نباید هر مرحله ای را که از نظر تئوری مهم است ثبت کنید. در اینجا یک قانون کلی خوب وجود دارد: سیاههها نباید از 10 درصد بار تجاوز کنند. در غیر این صورت مشکلات عملکردی وجود خواهد داشت.
2. ثبت همه داده ها در یک فایل در برخی مواقع، این کار خواندن/نوشتن گزارش را بسیار دشوار می‌کند، به غیر از این که سیستم‌های خاصی محدودیت‌هایی در اندازه فایل دارند.
3. استفاده از سطوح گزارش نادرست هر سطح لاگ دارای مرزهای واضحی است و باید به آنها احترام گذاشت. اگر یک مرز نامشخص است، می توانید در مورد اینکه از کدام سطح استفاده کنید به توافق برسید.

سطوح ورود به سیستم

سطوح لاگ چیست؟ به منظور ایجاد سلسله مراتبی از ورودی های گزارش، قراردادها و محدودیت های خاصی لازم است. به همین دلیل سطوح لاگ معرفی شدند. سطح در برنامه تنظیم شده است. اگر یک ورودی کمتر از یک سطح مشخص باشد، پس ثبت نشده است. به عنوان مثال، ما گزارش هایی داریم که هنگام اشکال زدایی برنامه از آنها استفاده می کنیم. در طول عملیات عادی (زمانی که برنامه برای هدف مورد نظر خود استفاده می شود)، چنین سیاهه هایی مورد نیاز نیست. بنابراین، سطح گزارش بالاتر از اشکال زدایی است. بیایید با استفاده از Log4j به سطوح log نگاه کنیم. به غیر از JUL، راه حل های دیگر از همان سطوح ورود به سیستم استفاده می کنند. در اینجا آنها به ترتیب کاهشی هستند:

• خاموش: هیچ ورودی ثبت نمی شود. همه چیز نادیده گرفته می شود
• FATAL: خطایی که مانع از ادامه اجرای برنامه می شود. به عنوان مثال، "خطا JVM out of memory".
• ERROR: خطاهای این سطح نشان دهنده مشکلاتی است که باید برطرف شوند. خطا به طور کلی برنامه را متوقف نمی کند. سایر درخواست ها ممکن است به درستی کار کنند.
• اخطار: ورودی های گزارش که نشان دهنده یک هشدار هستند. اتفاق غیرمنتظره‌ای رخ داد، اما سیستم توانست با آن کنار بیاید و درخواست را برآورده کند
• INFO: ورودی های گزارشی که اقدامات مهم در برنامه را نشان می دهد. اینها خطا یا هشدار نیستند. آنها رویدادهای سیستم مورد انتظار هستند.
• DEBUG: ورودی های گزارش باید برنامه را اشکال زدایی کنند. برای اطمینان از اینکه برنامه دقیقاً همان چیزی را که انتظار می رود انجام می دهد، یا برای توصیف اقدامات انجام شده توسط برنامه، به عنوان مثال "روش وارد شده 1".
• TRACE: ورودی های گزارش با اولویت پایین برای اشکال زدایی. پایین ترین سطح گزارش
• ALL: یک سطح گزارش برای نوشتن تمام ورودی های گزارش برنامه.

در سطح گزارش اطلاعات در جایی در برنامه فعال است، سپس ورودی‌های هر سطح، از اطلاعات تا FATAL، ثبت می‌شوند. اگر سطح گزارش FATAL تنظیم شده باشد، فقط ورودی های گزارش با آن سطح نوشته می شود.

ثبت و ارسال سیاههها: Appender

بیایید در نظر بگیریم که چگونه همه اینها هنگام استفاده از Log4j کار می‌کنند، که فرصت‌های زیادی برای نوشتن/ارسال گزارش‌ها فراهم می‌کند:

• برای نوشتن در یک فایل -DailyRollingFileAppender
• برای نوشتن اطلاعات در کنسول -ConsoleAppender
• برای نوشتن گزارش ها در پایگاه داده -JDBCAppender
• برای مدیریت ارسال گزارش ها از طریق TCP/IP —TelnetAppender
• برای حصول اطمینان از اینکه ورود به سیستم تأثیر منفی بر عملکرد ندارد -AsyncAppender

چند پیاده سازی دیگر وجود دارد: یک لیست کامل در اینجا موجود است . به هر حال، اگر ضمیمه مورد نیاز شما وجود نداشته باشد، مشکلی نیست. می‌توانید با پیاده‌سازی رابط Appender که Log4j از آن پشتیبانی می‌کند، اپندر خود را بنویسید .

گره های ورود به سیستم

برای اهداف نمایشی، ما از یک رابط Slf4j با پیاده سازی از Log4j استفاده خواهیم کرد. ایجاد یک لاگر بسیار ساده است: در کلاسی به نام MainDemo, که مقداری گزارش را انجام می دهد، باید موارد زیر را اضافه کنیم:

org.slf4j.Logger logger = org.slf4j.LoggerFactory.getLogger(MainDemo.class);

این یک لاگر برای ما ایجاد می کند. برای ایجاد یک ورودی گزارش، چندین روش موجود وجود دارد که نام آنها نشان می دهد که کدام سطح گزارش استفاده می شود. مثلا:

logger.trace("Method 1 started with argument={}", argument);
logger.debug("Database updated with script = {}", script);
logger.info("Application has started on port = {}", port);
logger.warn("Log4j didn't find the log4j.properties file. Please fix this.");
logger.error("Connection refused to host = {}", host);

اگرچه در حال گذراندن کلاس هستیم، اما نام نهایی، نام کامل کلاس، شامل بسته ها است. این کار به این دلیل انجام می شود که بعداً می توانید ورود به سیستم را به گره ها تقسیم کنید و سطح ثبت و پیوست را برای هر گره پیکربندی کنید. به عنوان مثال، لاگر در com.github.romankh3.logginglecture.MainDemoکلاس ایجاد شده است. این نام مبنایی را برای ایجاد سلسله مراتبی از گره های ورود به سیستم فراهم می کند. گره اصلی RootLogger سطح بالا است . این گره ای است که تمام ورودی های گزارش را برای کل برنامه دریافت می کند. گره‌های باقی‌مانده را می‌توان مانند شکل زیر نشان داد: ضمیمه‌ها برای گره‌های گزارش‌گیری خاص پیکربندی شده‌اند. حالا ما به فایل log4j.properties نگاه می کنیم تا نمونه ای از نحوه پیکربندی آنها را ببینیم.

راهنمای گام به گام فایل log4j.properties

ما همه چیز را یک مرحله در یک زمان تنظیم خواهیم کرد و خواهیم دید که چه چیزی ممکن است:

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender

این خط می گوید که ما در حال ثبت ضمیمه CONSOLE هستیم که از پیاده سازی org.apache.log4j.ConsoleAppender استفاده می کند. این ضمیمه اطلاعات را روی کنسول می نویسد. بعد، یک ضمیمه دیگر را ثبت می کنیم. این یکی در یک فایل می نویسد:

log4j.appender.FILE=org.apache.log4j.RollingFileAppender

توجه به این نکته ضروری است که خود ضمیمه ها هنوز باید پیکربندی شوند. هنگامی که ضمیمه های خود را ثبت کردیم، می توانیم تعیین کنیم که کدام سطوح log و کدام ضمیمه ها در گره ها استفاده خواهند شد.

log4j.rootLogger=اشکال زدایی، کنسول، فایل

• log4j.rootLogger به این معنی است که ما گره ریشه را پیکربندی می کنیم که شامل تمام ورودی های گزارش است.
• اولین کلمه بعد از علامت تساوی نشان دهنده حداقل سطح گزارش برای نوشتن است (در مورد ما DEBUG است)
• پس از کاما، تمام ضمائم مورد استفاده را نشان می دهیم.

برای پیکربندی یک گره ورود به سیستم خاص تر، می توانید از ورودی مانند زیر استفاده کنید:

log4j.logger.com.github.romankh3.logginglecture=TRACE, OWN, CONSOLE

کجا log4j.logger.برای ارجاع به یک گره خاص استفاده می شود. در مورد ما، com.github.romankh3.logginglecture. حالا بیایید در مورد پیکربندی ضمیمه CONSOLE صحبت کنیم:

# CONSOLE appender customization
log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.threshold=DEBUG
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern=[%-5p] : %c:%L : %m%n

در اینجا می بینیم که می توان سطح خاصی را تعیین کرد که در آن appender شروع به کار کند. در اینجا مثالی از آنچه در واقع اتفاق می افتد آورده شده است: فرض کنید یک پیام با سطح INFO توسط گره ورود به سیستم دریافت شده و به ضمیمه اختصاص داده شده به آن ارسال می شود. اگر آستانه ضمیمه روی WARN تنظیم شده باشد، ورودی گزارش را دریافت می کند اما هیچ کاری با آن انجام نمی دهد. در مرحله بعد، باید تصمیم بگیریم که پیام از کدام طرح استفاده کند. من در مثال از PatternLayout استفاده می کنم، اما گزینه های زیادی وجود دارد. ما آنها را در این مقاله پوشش نمی دهیم. مثالی از پیکربندی ضمیمه FILE:

# File appender customization
log4j.appender.FILE=org.apache.log4j.RollingFileAppender
log4j.appender.FILE.File=./target/logging/logging.log
log4j.appender.FILE.MaxFileSize=1MB
log4j.appender.FILE.threshold=DEBUG
log4j.appender.FILE.MaxBackupIndex=2
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=[ %-5p] - %c:%L - %m%n

همانطور که از این خط قابل مشاهده است، می توانید فایل خاصی را که ورودی های گزارش روی آن نوشته می شود پیکربندی کنید:

log4j.appender.FILE.File=./target/logging/logging.log

ورودی در logging.logفایل نوشته می شود. برای جلوگیری از مشکل در اندازه فایل، می توانید حداکثر که در این مورد 1 مگابایت است را پیکربندی کنید. MaxBackupIndexنشان می دهد که چه تعداد از این فایل های گزارش وجود خواهد داشت. اگر ما نیاز به ایجاد فایل های بیشتر از این داشته باشیم، اولین فایل حذف می شود. برای مشاهده یک مثال واقعی که در آن لاگ پیکربندی شده است، می توانید به مخزن عمومی در GitHub بروید.

آنچه را که بحث کردیم را تقویت کنید

سعی کنید همه آنچه را که توضیح دادیم به تنهایی انجام دهید:

• پروژه خود را مشابه مثال بالا ایجاد کنید.
• اگر می دانید چگونه از Maven استفاده کنید، از آن استفاده کنید. اگر نه، پس این آموزش را بخوانید که نحوه اتصال کتابخانه را توضیح می دهد.

به طور خلاصه

1. ما در مورد راه حل های ورود به سیستم که در جاوا وجود دارد صحبت کردیم.
2. تقریباً تمام کتابخانه های شناخته شده logging توسط یک نفر نوشته شده است :D
3. ما یاد گرفتیم که چه چیزی را باید و چه چیزی را نباید ثبت کرد.
4. ما سطوح ورود به سیستم را فهمیدیم.
5. ما با گره های ورود به سیستم آشنا شدیم.
6. ما بررسی کردیم که ضمیمه چیست و برای چیست.
7. ما یک فایل log4j.proterties را مرحله به مرحله ایجاد کردیم.

مواد اضافی

1. CodeGym: درس Logger
2. هفتگی Geekly: ثبت جاوا. سلام دنیا
3. ترسناک کدنویسی: مشکل ورود به سیستم
4. یوتیوب: درک جهنم ثبت جاوا - مبانی. Java Logging Hell و چگونه از آن دور بمانیم
5. Log4j: Appender
6. Log4j: طرح بندی

همچنین مقاله دیگر من را ببینید:

• اشکال زدایی در IntelliJ IDEA: راهنمای مبتدی