My first impression was "way to heavy"
But then again, I'm very happy with reporting of all WS calls of our OSB
environment end up in a database.
That is ofcourse somewhat different from what you describe, but I immediatly
thought of it.
The same ease of use (searching/filtering WS-calls) might apply in this case.
It saved a lot of time for us since we could easily trace WS calls (SOAP): body
and headers.
If you go that way, I suggest that reporting indeed is done in a different
database then the production one.
The reporting/logging can be quite extensive.
Best Regards,
Martijn
On 2016-01-15 14:50:03, Jeff wrote:
I know this is not directly a DBA question but I thought maybe someone
would have some experience.
My web team is wanting to implement a logging service which will log all
calls to their web services and info about who and what was called. And so
they are wanting to store this in the database in some table or tables.
Which basically means that every call to the database will generate an
additional call for logging. To me this seems like a bad idea to store in
the database. I am either thinking of creating a separate database just
for logging or well I don't know. I suggested just writing it all to a
file and use something like Splunk but for some reason which I haven't
found out yet they said that would not work for them.
Any suggestions/advice? Is this normal practice to log back to the database?
Attachment:
signature.asc
Description: Digital signature
