There are lots of other status codes - perhaps your "good" or expected not found should be a 3xx code (Redirection) or a 4xx that isn't 404
https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html On Wednesday, March 1, 2017 at 6:22:27 PM UTC+2, guettli wrote: > > nice, I like this. Yes, an additional header ... Thank you. > > Am Mittwoch, 1. März 2017 11:02:01 UTC+1 schrieb ludovic coues: >> >> I would tag the 404 in django and let the monitoring app do most of the >> work. >> The tag would simply be an extra header, x-reason for example. It would >> take values like "no mapping for url" or "object not found". >> >> This way, your django app is still doing no more than its job, indicating >> the ressources is unavailable, and this monitoring app have enough data to >> decide if the 404 should be logged or not. >> >> On 1 Mar 2017 10:54 a.m., "Antonis Christofides" < >> [email protected]> wrote: >> >>> My gut feeling says you should treat this in monitoring, however here >>> are some questions: >>> >>> 1) Why do you monitor 404s at all? >>> >>> 2) Could you give some examples of 404s that are valid or should be >>> ignored? >>> >>> Regards, >>> >>> Antonis >>> >>> Antonis Christofideshttp://djangodeployment.com >>> >>> On 03/01/2017 11:42 AM, Andreas Kuhne wrote: >>> >>> I think you should always report a 404 as a 404 regardless of the >>> situation. >>> >>> The application shouldn't have to know if it is a valid 404 or an >>> "invalid" - because from the applications point of view, the page (or item) >>> couldn't be found. >>> >>> Just my 2 cents. >>> >>> Regards, >>> >>> Andréas >>> >>> 2017-03-01 10:25 GMT+01:00 guettli <[email protected]>: >>> >>>> In systems which are accessed only via intranet we used to monitor http >>>> 404 responses. >>>> >>>> Every time a 404 happens, an issue in our monitoring gets created. >>>> >>>> This worked well in the past. >>>> >>>> Now we have cases where a 404 is valid or should be ignored. No issue >>>> in the monitoring should be visible. >>>> >>>> You could apply "separation of concerns" and keep on reporting all 404 >>>> responses >>>> and do the filtering in the monitoring area. >>>> >>>> But on the other hand the code knows more. I have places where I know >>>> that >>>> this 404 should be ignored. >>>> >>>> I am biased where the problem should get solved: >>>> >>>> - inside django app >>>> - inside monitoring >>>> >>>> >>>> What do you think? >>>> >>>> Does anybody make a differenence between "good 404 vs bad 404"? >>>> >>>> Regards, >>>> Thomas >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at https://groups.google.com/group/django-users. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-users/fb152b91-ee44-42aa-8304-fb43eba43be1%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/django-users/fb152b91-ee44-42aa-8304-fb43eba43be1%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/django-users. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/CALXYUbkcs%2BEqkNPLNhctqtEzB7Zd3oPKVoJUMNi8yzcXgON7bQ%40mail.gmail.com >>> >>> <https://groups.google.com/d/msgid/django-users/CALXYUbkcs%2BEqkNPLNhctqtEzB7Zd3oPKVoJUMNi8yzcXgON7bQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django users" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at https://groups.google.com/group/django-users. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-users/32a6faf0-a248-b983-2ad3-6dbc2d833927%40djangodeployment.com >>> >>> <https://groups.google.com/d/msgid/django-users/32a6faf0-a248-b983-2ad3-6dbc2d833927%40djangodeployment.com?utm_medium=email&utm_source=footer> >>> . >>> For more options, visit https://groups.google.com/d/optout. >>> >> -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/6a3320c1-de43-4b45-b6b1-e10e4cae2669%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
